Beyond the Mockery: Why We Should Embrace Testing Without Mocking Frameworks
summary
Argues that framework-generated mocks (Mockito) introduce runtime bytecode generation, shared mutable test state and brittle, API-unsafe stubs; shows a coffee‑maker example swapping a heater and pump to demonstrate constructor injection, Kotlin stubs and in-memory fakes that compile-safe catch API changes, and a fake that records interactions to verify outcomes. Recommends use fakes and stubs over runtime mocks, leverage Kotlin functional interfaces and IntelliJ refactor tools, and avoid mocking classes you own.
AI-written summary · about
chapters (10)
- 0:00Introduction and motivation
- 1:08Why testing matters in legacy projects
- 6:24Kotlin's role in better testing
- 11:20Refactoring dependencies for testability
- 14:08The problems with mocking frameworks
- 20:29Shared mutable state and test instability
- 25:42Stubs and fakes as better alternatives
- 30:35Interface segregation and seams
- 34:02Android's legacy challenges
- 36:31Conclusion and final thoughts
related talks
31mBeyond the Mockery- Why We Should Embrace Testing Without Mocking Frameworks
27mDe-mock your tests
19mHow to write a mock-free app
30mRefactoring and Test Fakes: Crafting Resilient Code with Confidence
41mMocks vs Fakes vs Stubs
29mTesting in Practice: Keeping Your Tests Concise and Declarative
01h 01m“Mocking Frameworks considered harmful”
25mFakes over Mocks: Shift your paradigm and identify monolithic code