Please don’t mock me
summary
Claim: a mocking library’s popularity is irrelevant if teams misuse it. Concrete examples show partial mocks and half‑real/half‑fake dependencies break builds; replacing some but not all collaborators hides bugs. Advice: wrap third‑party libs instead of stubbing them, prefer pure functions, and use London‑style discovery testing to drive design. The author ships test‑double (a Node library), demonstrates a tiny keynote‑generator prototype built by tests, and shows those patterns produce small, maintainable code.
AI-written summary · about
chapters (6)
- 0:00Start
- 1:41Uses a mocking library
- 2:35Unit Test
- 26:56Mocking in tests of existing code
- 41:08London-school Test-Driven Development
- 41:31Discovery Testing
related talks
39mPlease Don't Mock Me
28mTo mock, or not to mock?
31mBeyond the Mockery- Why We Should Embrace Testing Without Mocking Frameworks
37mBeyond 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
01h 01m“Mocking Frameworks considered harmful”
36mTo Mock or Not to Mock