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:

• Naming SUT Test Variables
• Naming Direct Output Variables
• Anonymous Variables
• Ignore Irrelevant Return Values
• testmethod Code Snippet
• 3 Is Many
• Why Use AreEqual<T>?
• Assert Messages Are Not Optional
• Use The Generate Method Stub Smart Tag To Stay In The Zone
• Test-Driven Properties

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

• Anonymous
  November 13, 2008
  The comment has been removed

• Anonymous
  November 20, 2008
  This is an installment in my Zero-Friction TDD series. Sometimes, you don't care about the return value

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

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

• Anonymous
  December 10, 2008
  This is a post in my Zero-Friction TDD series. One of my colleagues recently asked my why I prefer Assert.AreEqual&lt;T&gt;

• Anonymous
  December 16, 2008
  ...and now, in this week's episode of Zero-Friction TDD : Optional Assert messages that aren't optional

• Anonymous
  January 04, 2009
  Yet Another Zero-Friction TDD Article (YAZFTA): When writing unit tests in the TDD fashion, it's important

• Anonymous
  January 11, 2009
  Zero-Friction TDD post #10: In principle, defining properties (or fields, for that matter) while TDD'ing

• Anonymous
  May 17, 2012
  Sounds like a good idea; I will have to try that.