Testing: Integration Tests - The good, bad and ugly
summary
Argues for at least one test run against the real production component (for example testcontainers for Postgres or a real Kafka broker), keeping most integration tests fast with unique/random test data and cleanup, and avoiding brittle timing by avoid Thread.sleep and injecting a fixed Clock or using polling libraries (Awaitility/Spock). Use temporary queues and mock HTTP servers (WireMock) but add Pact contract tests between consumer and provider, and prefer targeted cleanup (delete by test id) so tests run in parallel.
AI-written summary · about
chapters (15)
- 0:00Introduction to integration tests
- 2:36Test pyramid vs Test Trophy
- 6:13Characteristics of good tests
- 8:42Using production components in tests
- 11:08Unique and random test data
- 13:58Avoiding testing anti-patterns
- 15:45Integration test configuration
- 16:27Time dependency in tests
- 21:07Database testing strategies
- 26:48Messaging systems integration
- 30:38HTTP service testing
- 33:46Contract testing for APIs
- 35:54File system integration
- 40:31Caching in integration tests
- 42:39Summary and best practices
related talks
46mTesting the untestable - patterns and use cases analysis
58mIntegration Testing from the Trenches
40mIntegration Testing from the Trenches - Rebooted
01h 20mIntegration Testing from the Trenches
37mUnderstanding the successes and the pain points of different testing strategies
44mTesting the untestable - patterns and use cases analysis
57mAdvanced Testing Techniques: Tips from the trenches
10mIntegration Testing – a thought experiment