To mock, or not to mock?
summary
Concrete rule set: use mocks when one of three questions is true — the test uses expensive resources, the code is non‑deterministic, or the component’s state can’t/shouldn’t be inspected. Examples use RSpec and rspec-mocks, a client pattern around a Shakespeare API, a custom ShakespeareError, an extractable ruby_words module for randomness, and a fake_sphere gem that caches quotes; mocks replace the external client or force errors so tests stay fast, deterministic, and decoupled.
AI-written summary · about
chapters (10)
- 0:00Mocking in testing intro
- 1:23What mocks are and challenges
- 3:29Classical vs mockist testing
- 6:57Risks of over-mocking
- 7:17When mocks add value
- 9:01Preventing expensive resources
- 14:16Deterministic tests for non-deterministic code
- 18:04Testing caches and hidden state
- 25:08When to mock framework
- 26:52Closing thoughts
related talks
36mTo Mock or Not to Mock
52mPlease don’t mock me
39mPlease Don't Mock Me
30mMocks, Stubs, and Spies, Oh My
22mA Mock Is a Promise: Making GraphQL Mocks Enforceable
31mBeyond the Mockery- Why We Should Embrace Testing Without Mocking Frameworks
45mStop Using Mocks (for a while)
25mFakes over Mocks: Shift your paradigm and identify monolithic code