Adversarial/Naive Pairing with TDD: How effective is it?

Question

A friend of mine was explaining how they do ping-pong pairing with TDD at his workplace and he said that they take an "adversarial" approach. That is, when the test writing person hands the keyboard over to the implementer, the implementer tries to do the bare simplest (and sometimes wrong thing) to make the test pass.

For example, if they're testing a GetName() method and the test checks for "Sally", the implementation of the GetName method would simply be:

public string GetName(){
    return "Sally";
}

Which would, of course, pass the test (naively).

He explains that this helps eliminate naive tests that check for specific canned values rather than testing the actual behavior or expected state of components. It also helps drive the creation of more tests and ultimately better design and fewer bugs.

It sounded good, but in a short session with him, it seemed like it took a lot longer to get through a single round of tests than otherwise and I didn't feel that a lot of extra value was gained.

Do you use this approach, and if so, have you seen it pay off?

Answer 1

I've used this approach. It doesn't work with all pairs; some people are just naturally resistant and won't give it an honest chance. However, it helps you do TDD and XP properly. You want to try and add features to your codebase slowly. You don't want to write a huge monolithic test that will take lots of code to satisfy. You want a bunch of simple tests. You also want to make sure you're passing the keyboard back and forth between your pairs regularly so that both pairs are engaged. With adversarial pairing, you're doing both. Simple tests lead to simple implementations, the code is built slowly, and both people are involved throughout the whole process.

Answer 2

It is based on the team's personality. Every team has a personality that is the sum of it's members. You have to be careful not to practice passive-aggressive implementations done with an air of superiority. Some developers are frustrated by implementations like

return "Sally";

This frustration will lead to an unsuccessful team. I was among the frustrated and did not see it pay off. I think a better approach is more oral communication making suggestions about how a test might be better implemented.

Answer 3

I like it some of the time - but don't use that style the entire time. Acts as a nice change of pace at times. I don't think I'd like to use the style all of the time.

I've found it a useful tool with beginners to introduce how the tests can drive the implementation though.

Answer 4

It can be very effective.

It forces you to think more about what test you have to write to get the other programmer to write the correct functionality you require.

You build up the code piece by piece passing the keyboard frequently

It can be quite tiring and time consuming but I have found that its rare I have had to come back and fix a bug in any code that has been written like this