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:
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:
- Giving one or more interfaces to a Jr team member for implementation
- Working tightly with a remote team member
- ??? 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.