TDD: Mocks, fakes, stubs, doubles, shunts ayayay!

💬 Summary

Note: This is a scheduled email series of our previous webinars that I’ve prepared for your summer break while I’m on vacation 🏝️ I’ll be back soon for our regular streams and coaching.

We dig into:

• What test doubles actually mean (and why teams misuse the terms)

• How mocks create tight coupling and when that’s okay

• Why test mess often signals deeper design issues

What if your team’s testing mess isn’t about TDD skills but a symptom of design decay?

In this webinar, I walked you through the chaos that emerges when mocks are overused, misunderstood, or left unexamined. I break down the difference between mocks, stubs, fakes, and shunts.

How they shape the tests we write and the systems we build. You’ll hear stories and patterns from coaching teams, and one simple rule: when tests feel messy, your code probably is too.

Engineers often misuse the term mock for anything test-related—leading to confusion and tangled code. Frameworks labeled as “mocking” tools often create stubs, not mocks.

If your mocks return mocks, and your test reimplements the full logic of the system, you've lost the plot. That’s not a test—it’s a clone of production.

Mocks make sense only when testing outgoing commands—void-style operations like sending emails. It’s not about the result, it’s about the side effect.

When a simple test takes a dozen lines of mocking setup, that’s not bad testing—that’s a sign your code is hard to reason about.

Mock-heavy tests were never meant to be the goal. The London school uses mocks to explore architecture—not to overload tests with dependencies.

👉 Watch the full recording above.
✉️ Subscribe to get the rest of this 5-part vacation deep dive series.
💬 Got a team drowning in mocks or struggling with TDD clarity?

Reply to this post — I’d love to hear your challenges.

Thank you Simon Jefferies, Thomas Innovation Engineering, and many others for tuning into my live video! Join me for my next live video in the app.