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.
