Too Many Mocks Kill the Test: What Hexagonal Architecture Changed
summary
Explains how overusing mocks harms automated tests and how adopting a hexagonal (ports and adapters) architecture reduces that problem. Describes the testing issues caused by tight coupling and excessive mocking, and shows how hexagonal architecture separates core domain logic from external dependencies (databases, HTTP, etc.) so tests can be more focused and less mock-heavy.
AI-written summary · about
chapters (12)
- 0:00Introduction
- 1:09Locking Tests vs. TDD
- 5:32Misconception #1
- 7:11Misconception #3
- 14:48Misconception #4
- 18:13Infrastructure: Integration Testing
- 19:03Misconception #5
- 20:24Suggestion
- 25:19Misconception #6
- 25:471st Test: Well-Defined Boundary
- 35:00Misconception #7
- 39:46Your Turn!
related talks
30mMastering Testing in a Hexagonal Architecture
25mHexagonal Architecture in Monoliths and Microservices
01h 01mWhy not all hexagons have eight sides
37mTDD and Hexagonal Architecture in Microservices
45mWhy Hexagonal and Onion Architecture Are Answers to The Wrong Question
47mHexagonal Architecture Level 2: How to write well…
31mBeyond the Mockery- Why We Should Embrace Testing Without Mocking Frameworks
52mWhy not all hexagons have eight sides