May 19, 2005
Independent Test Driven Development
There are quite a few development styles that exist in the area of software development. One of these is labeled "Extreme Programming". Besides having an edgy name, this style of development suggests many outside the box ideas for improving both the quality and speed of delivery for developing systems. Personally I'm a little skeptical of some of the methods, but one concept that does intrigue me is test driven development within a pair programming environment.
Personally I'm not the biggest fan of pair programming. I really don't like the idea of someone looking over my shoulder arguing with me about tabulation in my code. However, I do like the concept of pair development. The major difference between these two is found in execution. During pair development one person functions as the author of the code while both people participate in each design cycle. The team meets together to design the next cycle for the code and then the author works independently implementing the agreed upon design. This approach creates blocks of time that the non-author can spend creating tests for the developing code.
What intrigues me about this approach is that the developed test scripts are created based upon the design - not based strictly on the actual code. In concept, Unit Tests should be designed to test the inputs and outputs of each block of code. All to often the code author has certain pre-conceived ideas about the permutations of the environment and data that can be sent through each code block. If the test script author is the same as the code author, these pre-conceived ideas also drive the test script that is created and can lead to bugs not being discovered until the Integration Testing phase. If the test script is authored by an alternate person then the code author, the code benefits from being tested from an independent source. This independent source will be primarily concerned about the functional responsibility of the code and less concerned about how to test every functional block.
During a recent development effort, the schedule for delivery actually forced us to use this concept for a code maintenance release. For this effort I was the code author and I was quite concerned about developing code without developing the test script in parallel. I found that I was quite uncomfortable without the "guess and check" process I was familiar with. However what actually transpired is that I spent more effort on ensuring the quality of my code due to the risk of embarrassment when my code was evaluated. Additionally, the developed test script determined additional modifications necessary in the code that I would have not conceived of due to my perspective of the functionality.
I don't feel this experiment proves the validity of the approach, but I do believe that it provides incentive for a purposeful implementation in the future.
Posted by Jason Boyd at May 19, 2005 11:52 PM
Trackback Pings
TrackBack URL for this entry:
http://www.jandrconsult.com/cgi-bin/mt/mt-tb.cgi/55