TDD is a process that provides constant confirmation to the development team.
Writing the tests up-front confirms that there is sufficient understanding of requirements so that they can be expressed in the rigorous form of a unit test. Alternately, it reveals that this understanding has gaps and reveals questions that need to be answered.
The quality of the test mirrors the quality of the system, and so if “good” tests (as I have defined them) can be written, this is confirmation of a good design.
Running the test initially and watching it fail confirms that the test is legitimate. One potential mistake in TDD is writing a test that has no way to fail. Seeing it fail confirms that this kind of error has not been made.
Making the test pass confirms that the work done on the system produces the correct behavior. And seeing all the pre-existing tests continue to pass confirms that only the intended change was made.
This constant confirmation breeds a kind of confidence that is traditionally rare in software development. Such confidence is attractive to developers: once they experience it, they never want to go back! It also leads to aggressiveness.
Aggressiveness in a good sense. So that you can stay competitive in the modern marketplace.
-AMAZONPOLLY-ONLYAUDIO-START-
This is Scott Bain. Visit us at www.netobjectives.com.
-AMAZONPOLLY-ONLYAUDIO-END-