On Sat, Apr 01, 2006 at 04:04:42PM -0800, Jeffrey Thalhammer wrote: > I have never actually had an opportunity to practice > this, but I've always felt that the most obvious way > to combine test-driven development with pair > programming was to have one person write test code > while the other person writes application code. > Presumably they might change roles periodically, but > I'm not sure if they would actually work at the same > terimnal. However, I've never heard anyone > excplicitly advocate for this approach. Is this > actually happening and I'm just not aware of it? Or > is there some obstacle to this approach that I haven't > considered?
I wouldn't call "one person write test code while the other person writes application code" pair programming. I'd call it two people programming. What makes pairing good is the increased attention to code as it comes out. The pair discusses the implementation, which not only finds lots of simple bugs very early, it also: - transfers knowledge extremely fast - focuses on solving the problem at hand in the simplest way possible - encourages code refactoring and other good practices - builds discipline and respect in the team At $work, we have pairing stations that have two monitor/keyboard/mouse sets plugged into the same machine. This gives each person their own physical space, and makes it super easy to switch drivers. I have to admit, I totally thought it was hokey when I heard of this setup. But having used it with lots of different peers for various activities, I really like it. I was recently pairing on some new code to extend an existing system. We first wrote a simple test to check if the script we were writing existed and was executable. Fail... hack hack... Pass! Next up, write a test to show usage. Hmm, now we have to figure out roughly what our interface will be. Hack hack... Pass! At some point, we needed to re-use some functionality from another module. We needed to hack an extra parameter into a utility function. I wanted to just make the change and then get back to our other tests, but my peer nagged me to write unit tests first. So we did, first for the (currently untested) function with its normal behaviour, and then for the new functionality we needed. After a few more hours of hacking not only did we have some correctly functioning code with full unit tests, not only did we not create a knowledge silo in this area, not only did we have new tests for previously untested code, but it was fun, fast and we both learned new things. I really think that Test driven development is like developer crack. Except instead of being high for days and destroying your life, you're writing clean code with full unit tests. Luke -- Luke Closs PureMessage Developer There is always time to juggle in the Sophos Zone.
