De-mock your tests
summary
Argues that overusing Mockito/MockK harms code and shows concrete replacements: implement a fake database using an internal list/map instead of method-by-method mocks, convert single-use interfaces into functional single-method providers to stub suspend calls in plain Kotlin, record UI interactions with a view-robot that stores state changes rather than verify calls, and plant a Timber test tree to collect log entries. Recommends mocks only for unmodifiable legacy or final classes; fakes improve readability, reuse, and portability to multiplatform.
AI-written summary · about
chapters (13)
- 0:00Introduction and story
- 1:32Unit testing basics
- 3:22Test doubles and mocks
- 5:09Mocking database with fakes
- 7:41Stubbing use cases
- 10:32MVP testing with view robots
- 13:42Testing side effects
- 14:48Mocking callbacks
- 17:42Mocking static methods
- 20:12Removing static mocks
- 21:57When to use mocks vs fakes
- 24:07Mocking anti-patterns
- 26:16Summary and conclusion
related talks
37mBeyond the Mockery: Why We Should Embrace Testing Without Mocking Frameworks
29mTesting in Practice: Keeping Your Tests Concise and Declarative
41mMocks vs Fakes vs Stubs
19mHow to write a mock-free app
31mBeyond the Mockery- Why We Should Embrace Testing Without Mocking Frameworks
30mRefactoring and Test Fakes: Crafting Resilient Code with Confidence
25mFakes over Mocks: Shift your paradigm and identify monolithic code
36mMocks, Stubs, and Spies, Oh My!