Blog

  • Home /
  • Blog /
  • Tales Of TDD: One Test Double To Rule Them All

Tales Of TDD: One Test Double To Rule Them All

March 5, 2026

So I’ve encountered this specific test case, which is quite elaborate.

What do you mean by that?

Well, it contains a lot of code, and also looks more difficult to understand compared to the other test cases.

Yeah, that’s because of the Fake we’re using in our test code.

So, the test code is complex because we’re using a Fake?

Yes, I’m afraid so. The test scenario embodies a specific edge case. The Subject Under Test should initiate a recovery only when the collaborator raises an InvalidValueException.

That does align with the functionality we discussed earlier.

I had to do all this setup in the test method just to force the Fake to throw an InvalidValueException.

I see. I agree that it’s sometimes not easy to make a Fake behave exactly as you want.

Tell me about it. It took me almost an hour to figure out how to make it throw an exception. I really like using Fakes in our tests because they behave just as the real implementation. But sometimes, they can be a real pain to work with as well.

Have you considered using a Stub instead of a Fake?

A Stub? No, not really. We decided in a team meeting to use Fakes instead of Stubs, Spies, or Mocks

I understand. I’m not suggesting you stop using Fakes altogether. But have you considered not using a Fake just for this specific test case? Would it make the test easier to understand if you used a Stub that raises an InvalidValueException instead?

Yeah, but that’s not what we agreed on in the team meeting.

I’m sure what was agreed on was more of a guideline than a strict rule. How about we just try it out? Let’s change the test code to use a Stub instead of a Fake.

OK. We can do that.

… After short while …

Now the test is just four lines of code. What do you think?

Yeah, it’s a lot more concise and readable.

Do you want to keep it like this?

Sure! But shouldn’t we change all the other tests to use a Stub for that collaborator as well?

Why do you want to do that?

Because that way, it’s more consistent.

If consistency is what we’re after, then I agree with you. But what do we ultimately want from our tests?

That they fail when we have an issue in the production code.

Yes, and what else?

That they are readable and easy to understand.

Exactly! There’s no reason to be dogmatic about test doubles. We can just use the one that best fits our purpose. So it’s perfectly fine to use Fakes for most of the tests, while using a Stub for this specific test case as a one-off.

I see that now. So I don’t need to stick with one specific type of test double? That’s very cool. I can’t wait to show this off at our next team meeting.

If you and your team want to learn more about how to write maintainable unit tests and get the most out of TDD practices, make sure to have look at my trainings and workshops or check out the books section. Feel free to reach out at infonull@nullprincipal-itnull.be.

Profile picture of Jan Van Ryswyck

Jan Van Ryswyck

Thank you for visiting my blog. I’m a professional software developer since Y2K. A blogger since Y2K+5. Provider of training and coaching in XP practices. Curator of the Awesome Talks list. Past organizer of the European Virtual ALT.NET meetings. Thinking and learning about all kinds of technologies since forever.

Comments

Latest articles

Tags

Disclaimer

The opinions expressed on this blog are my own personal opinions. These do NOT represent anyone else’s view on the world in any way whatsoever.

About

Thank you for visiting my website. I’m a professional software developer since Y2K. A blogger since Y2K+5. Author of Writing Maintainable Unit Tests. Provider of training and coaching in XP practices. Curator of the Awesome Talks list. Thinking and learning about all kinds of technologies since forever.

Latest articles

Contact information

(+32) 496 38 00 82

infonull@nullprincipal-itnull.be

principal-it.eu
principal-it.be
janvanryswyck.com