Mocks vs Fakes vs Stubs
summary
Argues that heavy use of Mockito encourages tests that mirror implementation and break on refactor, and demonstrates replacing mocked views with a fake view that records UI state so tests assert outcomes not interactions. Shows a simple Android MVP example where three tests (success, loading, error) shrink and stabilize when using fakes and shared fake state, recommends a small factory objects pattern for test data, and promotes ping‑pong and intentional code mutation to validate test quality.
AI-written summary · about
chapters (15)
- 0:00Introduction
- 1:15Why write unit tests
- 14:08Test Quality
- 14:48Test Implementation
- 15:58Fakes
- 16:35Test View
- 19:22Use Cases
- 21:35Data Class
- 23:35Unit vs Class
- 25:32The preferred solution
- 27:38Unit testing
- 31:26Refactoring
- 33:45UI test
- 35:45Integration test
- 38:15Account state
related talks
27mDe-mock your tests
37mBeyond the Mockery: Why We Should Embrace Testing Without Mocking Frameworks
42mMocks, Fakes, Stubs – Is There a Difference? Do You Still Need Them?
36mMocks, Stubs, and Spies, Oh My!
31mBeyond the Mockery- Why We Should Embrace Testing Without Mocking Frameworks
25mFakes over Mocks: Shift your paradigm and identify monolithic code
30mMocks, Stubs, and Spies, Oh My
30mRefactoring and Test Fakes: Crafting Resilient Code with Confidence