Test Doubles are Not To Be Mocked
summary
Claim: test doubles (mocks/spies) reveal assumptions rather than inherently breaking tests. Example: a price calculator test either creates two Active Record tickets and a discount (two $20 tickets minus $25 = $30) or uses spies that assert a ticket#price_check call. Rails and Active Record make isolation painful; external APIs like Stripe belong behind stubs. Tests get judged by SWIFT and using verified doubles plus at least one end‑to‑end integration test proves the pieces actually work together.
AI-written summary · about
chapters (26)
- 0:00Intro
- 1:03This is the talk about test doubles
- 1:52book
- 9:27Long term priorities might be different
- 9:47A A good test Leads
- 10:08Behavior validation
- 10:40A Tale of Two Tests
- 13:25State: uses real objects, expectation on state Spy : uses test doubles, expectations on behavior
- 16:04The code can be wrong and the double test will
- 16:28This is a matter of perspective
- 17:52The test can fail even though the test is right
- 18:26Design goal: A failure state causes exactly one test to fail
- 19:00Doubles test the design and the behavior
- 20:11The double encourages the creation of additional tests
- 20:57It encourages good design practices
- 21:41The design might change
- 22:43More isolation that many people are comfortable committing to up front
- 23:41Test doubles are design canaries
- 24:36Lot of setup might mean poorly factored design
- 26:02This level of isolation is hard on a team if you are the only one who cares
- 27:55A third-party framework can make this hard
- 29:18I was unwilling or unable to make the code isolated enough to keep the spies
- 30:33Conway's law applies to tests
- 31:17Think about what will make your tests fail
- 32:04Try writing Rails tests with isolation
- 32:35Using an integration test can force additional unit tests
