For those of you struggling to understand the different approaches to testing being heralded in by the TDD community I strongly encourage you read the following article:

TDD Tests are not Unit Tests

Stephen does an excellent job of detailing the general purpose behind the testing styles and really clarifies for my why I tend to disagree with many of the assertions about unit testing from the TDD community. First let me say I don’t do TDD, and generally I fundamentally disagree that it produces better software.

What I do believe in is testing your code via unit tests (call it integration testing, acceptance testing, whatever). I have been testing code via NUnit since 2002. Perhaps I may be set in my ways, I just can’t seem to join the TDD ‘gold rush’. There might be a reason for TDD (test before code) if you are doing one of the following:

  1. Giving one or more interfaces to a Jr team member for implementation
  2. Working tightly with a remote team member
  3. ??? Ok, short list because I can’t find any other reason ???

Maybe I’m crazy, but ensuring product/component stability and a general confidence in changes are the only goals for me. With one side benefit of either learning an API or providing a sample usage of one.

Comments