Unit testing verifies that one software component behaves correctly in isolation. For Kafka applications, it checks service behavior around messages without requiring a Kafka cluster, while integration testing validates communication with Kafka and other external components. section 10.3.1
Effective unit tests emphasize observable behavior and keep infrastructure outside the test boundary:
- Assert public behavior, such as return values, state changes, downstream interactions, or the data passed to a Kafka producer. section 10.3.1
- Replace producers, consumers, and other dependencies with mocks or fakes so tests avoid network communication and cluster involvement. section 10.3.1
- Invoke a consumer handler directly with a deserialized message when simulating message delivery. section 10.3.1
- Avoid testing private methods directly; extract important logic or expose a minimal API when necessary. section 10.3.1
- Keep the trade-off visible: meaningful coverage requires development and maintenance effort, and tests coupled to implementation details can fail incorrectly. section 10.3.1
ProfileService in a Customer 360 ODS
A unit test invokes ProfileService with test input and verifies its observable behavior: the return value or whether the producer was called as expected. It does not verify that Kafka actually accepts or delivers the message; that behavior belongs to integration testing. A consumer-side test can invoke Customer360Service’s handler with a deserialized Kafka message and inspect state changes or downstream interactions. section 10.3.1
Figure 10.4 Unit testing of the ProfileService component. The test invokes the service with test input and verifies its behavior without involving a Kafka cluster. Evaluation is done by inspecting the return value or verifying that the producer was called as expected.
Shows the isolated producer test boundary: test input enters the service, while evaluation uses return values or producer-call verification without a Kafka cluster. section 10.3.1
