Test Driven Development (TDD) is a development process based on very short testing and coding iterations where the test code for a block of functionality always precedes any actual implementation. A test should be written to fail before coding any sort of implementation; this follows the Red-Green-Refactor idea. I have been exposed to TDD in the past year or so and actually practiced it a little without knowing it while working on college projects.
The development team I belong to consists of Christian Hargraves (a strong proponent of TDD) and me. As a team we’ve been trying to do TDD and pair programming at least a couple of times a week. Our pattern is for one developer to write the unit test and create any classes or methods required to simply make the code compile and the test fail. At this point, the other developer takes the helm and does the bare minimum to make the test pass. He then writes the next failing test. The result is that the simplest solution is implemented first. This cycle continues until both developers are confident that the functionality will meet all the requirements and that the tests are all passing. This method of development is often referred to as ping pong programming.
Continue reading at the original source →