A testable architecture
summary
Argues that a testable architecture is doable by designing the core as ports and adapters and driving behavior with executable specs (Gherkin via gherkin/cucumber). Shows a fast in-memory stub vs SQL adapter pattern: in-memory repos run in milliseconds for day‑to‑day dev, SQL/JDBI+H2 integration tests run seconds and are few, and a handful of Selenium UI scenarios exist. Reuses the in‑memory driver across ~70 tests, runs ~1,800 unit tests in ~12s, and supports frequent deploys for a ~800‑user app.
AI-written summary · about
chapters (17)
- 0:00Start
- 0:33Questions?
- 3:09Three concepts
- 4:39Testing
- 6:07Living documentation
- 11:37The prerequisites are know
- 12:32Connect the specification to the code
- 13:27Blissfully ignorant of the driver's technology
- 15:43What is a seam?
- 21:00Why a stub and not a mock?
- 23:03A repository test
- 25:30Let's run the tests
- 26:40The actual repository adapter
- 30:31A patch work
- 32:51If all the tests passes...
- 34:53Our domain
- 36:52Conclusion
related talks
25mTestable Architecture: Keep 'em Separated
21mTestable Architecture: Keep 'em Separated
53mThe Grand Unified Theory of Clean Architecture and Test Pyramid
53mTest architecture is a real thing
47mThe Grand Unified Theory of Clean Architecture and Test Pyramid
46mThe Road to Improving Testability
41mSoftware Architecture — Yes, on Tests
01h 34mThe Intersection of Architecture and Implementation