An integration test checks that multiple application components and their external dependencies interact correctly. Unlike a unit test, it uses the real dependencies rather than mocks, trading subsecond execution for broader, slower validation. section 14.1
For Kafka Streams, the test runs a live Kafka broker, starts the topology, produces timestamped records, consumes output, and compares the results with an expected sequence. This verifies the assembled application rather than one operator in isolation. section 14.1.5
A practical integration-test workflow includes:
- Start and manage a Kafka broker in a Docker container with Testcontainers and JUnit 5. section 14.1.5
- Configure Kafka Streams, producers, and consumers with the container's bootstrap server. section 14.1.5
- Start the topology, wait until Kafka Streams reaches the RUNNING state, and feed it test records. section 14.1.5
- Clean up topics after each test while reusing a static container when appropriate to reduce startup cost. section 14.1.5
Testing a hopping-window count
A JUnit 5 test sends six groups of records for the key "Foo" at timestamp intervals, reads the output topic, and asserts counts that rise from 1 through 21 before declining as records leave the hopping window. section 14.1.5
Table 14.1 Unit testing compared to integration testing
|
Type
|
Purpose
|
Speed
|
Percentage of use
|
|---|---|---|---|
|
Unit
|
Method level, finer-grained logic, objects in isolation
|
Subsecond
|
Majority
|
|
Integration
|
Holistic, integrated components, course grained
|
Seconds to minutes
|
Minority
|
Compare integration tests with unit tests by purpose, execution speed, granularity, and typical share of the test suite. section 14.1
