Integration Testing from the Trenches
summary
Argues that both unit tests and integration tests are mandatory, because units alone miss integration faults and full-system tests are too slow and fragile. Recommends separating suites (fast unit phase then slower integration phase), using Maven failsafe plugin and dedicated CI jobs (hourly/daily) for integration tests, using H2 in-memory database or per-developer Oracle schemas to avoid flakiness, faking web services with lightweight servers (Spark) or SoapUI APIs, and exercising Spring with MockMvc (@WebMvcTest), noting Spring Test rolls back by default and @Commit forces commits.
AI-written summary · about
chapters (15)
- 0:00Introduction to testing
- 1:58Defining integration tests
- 4:28System under test scope
- 7:08The testing pyramid
- 8:33Common testing challenges
- 10:42Maven build lifecycle
- 14:00Infrastructure challenges
- 17:04Database testing strategies
- 22:11Mocking web services
- 27:21Best practices for tests
- 29:13Spring configuration
- 33:46Managing connections
- 36:41Spring transaction testing
- 40:16Spring Boot testing
- 47:47Q&A and final remarks
related talks
01h 20mIntegration Testing from the Trenches
40mIntegration Testing from the Trenches - Rebooted
44mTesting: Integration Tests - The good, bad and ugly
01h 46mHow Java developers should test their applications (RU)
42mUse testing to Develop Better Software Faster
56mTesting for Success in the Real World
57mAdvanced Testing Techniques: Tips from the trenches
41mTesting done right: From bugs to brilliance