A service can pass a unit test and still fail to exchange messages through Kafka. An integration test crosses that boundary: it checks that components communicate through the agreed contract and protocol, rather than only checking how they behave in isolation. section 10.3 section 10.3.1
For Kafka clients, the distinction is practical. A unit test can use a mock to check that a service calls its producer or handles a supplied message. An integration test involves Kafka to verify that the producer publishes, the cluster retains the message, and the consumer retrieves and processes it. Load and throughput belong to performance testing, not this check. section 10.3.1 section 10.3.2 section 10.3
Test each side of the message flow from outside its Kafka boundary:
- Producer: invoke the service, consume its message from the topic with a test consumer, and check the content and relevant metadata, such as headers, partition, or offset. section 10.3.2
- Consumer: publish with a test producer, then check what the consumer passed to service logic or what effects processing produced. Mockito’s ArgumentCaptor can inspect the arguments passed to a service method. section 10.3.2
Choosing a broker for the test
An embedded Kafka broker lets a producer or consumer test exchange messages without an external cluster. Testcontainers instead launches a real Kafka broker in a Docker container for the test. A dedicated cluster is possible, but adds infrastructure overhead. The choice is how to run the Kafka interaction reliably, not whether to replace it with a mock. section 10.3.2 section 10.3.1
Figure 10.11 Integration testing of ProfileService using a Kafka cluster launched via Testcontainers. The test code starts a real Kafka broker inside a Docker container, invokes the service, and validates that the message was correctly sent to the Kafka topic.
The diagram shows a service publishing to a Kafka broker launched by Testcontainers, with test code checking the message in the topic. section 10.3.2
