* Jeffrey Thalhammer <[EMAIL PROTECTED]> [2006-04-02 02:05]: > 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.
Seems awkward to me. The idea of test-*driven* development is that the guy who writes application code writes only as much as is necessary to pass the existing tests – the two can’t be done independently of each other to the extent that you seem to be suggesting. Also seems to miss the point. The idea of writing tests first is that you get a feedback loop between a) designing and using an API prior to implementing it and b) attempting to implementing the design. That is, you get a feedback loop where the API design and the implementation process inform each other. The process you suggest seems more applicable to cases where there already is a very precise design spec and the development effort is solely straightforward implementation. In that case, yes, one developer can write tests and another can write the implementation. So, it depends. Most of the time, your idea is not applicable; but sometimes, such as when you’re implementing a standard (say, you’re writing a HTTP library or an XML parser or whatever), it is a good approach. Regards, -- Aristotle Pagaltzis // <http://plasmasturm.org/>
