Beyond the Mockery- Why We Should Embrace Testing Without Mocking Frameworks
summary
Argues that heavy use of Mockito creates brittle, slow, and hard-to-read tests: Mockito returning nulls and mocks returning mocks hide failures, suffer type-erasure surprises, deep-stub footguns, and generate shared mutable state. Recommends constructor injection, immutability and small interfaces, then replacing expensive or third-party dependencies with tiny stubs or hand-coded fakes (example: an in-memory fake coffee-stock repository) that run fast, reveal API changes at compile time, and verify resulting state instead of internal interactions.
AI-written summary · about
chapters (7)
- 0:00Introduction and motivation
- 3:41Testing challenges and anti-patterns
- 10:23Problems with mocking frameworks
- 16:23Costs of unpredictability in mocks
- 21:03Stubs and fakes as alternatives
- 25:38Seams and interface segregation
- 29:30Conclusion and final advice
related talks
37mBeyond the Mockery: Why We Should Embrace Testing Without Mocking Frameworks
27mDe-mock your tests
19mHow to write a mock-free app
29mTesting in Practice: Keeping Your Tests Concise and Declarative
41mMocks vs Fakes vs Stubs
30mRefactoring and Test Fakes: Crafting Resilient Code with Confidence
39mPlease Don't Mock Me
01h 01m“Mocking Frameworks considered harmful”