Zero-Friction TDD


Writing good code is difficult. Unit tests are written as code, so a corollary to the first sentence is that writing good unit tests is also difficult.


TDD (particularly if you interpret the last D as Design) carries this challenge in abundance, since you ought to be focusing on designing your SUT, but you might end up spending a lot of energy on ensuring the readability and maintainability of the tests themselves.


The goal is Zero-Friction TDD. To me, this means that you should be able to focus entirely on designing the SUT. Writing the test should present as little productivity friction as possible.


Writing a test will always require some attention to the test itself, but any trick you can use to take your mind off the test will enable you to better focus on the SUT. Every time you have to think about how to write the test instead of how to design the SUT, you make a context switch, and each of these cost you productivity.


This means that even if a given optimization strategy may seem insignificant in itself, a lot of these can go a long way towards keeping you in the zone.


I’ve already posted one example, where I describe a few arguments for naming SUT test variables sut. The argument I didn’t present is that it frees you from thinking about a good name for the variable. In the context of that post, such an argument would have seemed trifling, but in the broader context, it saves you from one context switch and enables you to move on with writing the test.


In future posts, I will share other tricks you can use to focus your mental energy on designing the SUT, while still writing good unit tests.


Update: Posts in the series:



Update: While I was publishing this series of posts, my employment at Microsoft came to an end. Please see my new blog for an updated list of Zero-Friction TDD posts.

Comments (9)

  1. ploeh blog says:

    In my series of Zero-Friction TDD tips and tricks, it’s time to look at naming Direct Output variables.

  2. ploeh blog says:

    This is an installment in my Zero-Friction TDD series. Sometimes, you don’t care about the return value

  3. ploeh blog says:

    This is an installment in my Zero-Friction TDD series. If you are a regular reader of this blog, you

  4. ploeh blog says:

    This is an installment in my Zero-Friction TDD series. When I was a kid, my parents taught me that many

  5. ploeh blog says:

    This is a post in my Zero-Friction TDD series. One of my colleagues recently asked my why I prefer Assert.AreEqual<T>

  6. ploeh blog says:

    …and now, in this week’s episode of Zero-Friction TDD : Optional Assert messages that aren’t optional

  7. ploeh blog says:

    Yet Another Zero-Friction TDD Article (YAZFTA): When writing unit tests in the TDD fashion, it’s important

  8. ploeh blog says:

    Zero-Friction TDD post #10: In principle, defining properties (or fields, for that matter) while TDD’ing

  9. BillW33 says:

    Sounds like a good idea; I will have to try that.

Skip to main content