a few days ago, I blogged about “what is the right level of detail to describe an interface,” and one good soul asked me to include unit tests.

OK.  I like Test Driven Development.  I really do.  I think it is an excellent practice that forces you to think in “specification completeness” terms, which is not something that comes naturally… it is learned.

But honestly, if I am communicating with a person who has not learned to think this way, then a unit test is code.  It is not a spec.  And if I am communicating with a person who is a program manager, and not a developer, then a unit test is code, not a spec.  And if I am communicating with a person who loves unit tests, but only in their favorite tool, then a unit test may cause “more heat than light.”  None of these three people will gain much from a unit test.

When I am communicating, I don’t always know who I am communicating with (like right now).  So unit tests, while valuable and useful for the person who is writing the code, and valuable and useful for the people who need to validate the code and maintain the code and even understand the code, are not always the best way to communicate about the code to an unknown but hightly technical audience.

Pictures.  Diagrams.  The friggin’ UML, for goodness sake.  (High fidelity diagrams).  I can, in four diagrams, illustrate more about an interface’s dynamic behavior than I can in a long list of unit tests. 

Let’s use TDD.  Let’s promote TDD.  But let’s know it’s limitations.