Adversarial / Naive pairing with TDD: how effective is it?

Question

One of my friends explained how they ping pong mate with TDD in their workplace, and he said that they take a “competitive” approach. That is, when the user responsible for the test passes the keyboard to the developer, the developer tries to do a simple (and sometimes wrong thing) to pass the test.

For example, if they test the GetName () method, and check the check for "Sally", implementing the GetName method will be simple:

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

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

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

It sounded good, but in a short session with him it seemed like a lot more time had passed to pass one round of tests than otherwise, and I didn’t feel that much extra value was gained.

Do you use this approach, and if so, have you seen its redemption?

Answer 1

It is based on the personality of the team. Each team has an identity, which is the sum of its members. You must be careful not to practice passively aggressive implementations done with excellence. Some developers are disappointed with the implementation, for example

return "Sally";

This disappointment will lead to an unsuccessful team. I was among the disappointed and did not see him pay off. I think the best approach is a more verbal message that offers suggestions on how to conduct the test better.

Answer 2

It can be very effective.

This makes you think more about which test you should write to get another programmer to write the functionality you need.

You often create code piece by piece, often skipping the keyboard

It can be quite tedious and time consuming, but I found that its rare I had to go back and fix the error in any code that was written this way

Answer 3

I used this approach. It does not work with all couples; some people are just naturally stable and will not give him an honest chance. However, it helps you do TDD and XP properly. You want to slowly add functions to your codebase. You do not want to write a huge monolithic test that will require a lot of code to satisfy. You want a bunch of simple tests. You also want you to regularly walk the keyboard back and forth between your pairs to engage both pairs. With competitive mating, you do both. Simple tests lead to simple implementations, the code is created slowly, and both people are involved throughout the process.

Answer 4

I like this for a while - but don't use this style all the time. Acts like a nice change of pace at times. I don’t think I would like to use the style all the time.

I found this a useful tool for beginners to introduce how tests can control implementation, though.