Separate Coding And Testing

Our next project will be developed using UnitTests (one small step for man...). But our ProjectManager wants to put a twist on them. He would like to have a first group of developers write tests that a second group will write the code to pass. This would mean that somebody other than me writes the tests for the code I am going to write. His feeling is that this will make sure that at least four people have read (and presumably understood) the spec before moving to implementation.

Intuitively I feel that this will cause problems and will slow down the pair that are coding as they run back to the "testing pair" to get new tests.

Does anybody have any experience with this positive or negative? -- IainLowe

No experience with this in an XP context, but it sounds bad - the point of writing the tests is to give the programmer insight into the problems of writing the module. Having the tests handed to me would make it harder to get that knowledge.

A big part of TestFirstProgramming is the fact that the tests drive development. What your manager is proposing is FunctionalTesting, not UnitTesting. How can you write UnitTests for code you're not writing? The only good way to do it is to write the code shortly after you write the tests. More often than not, the tests are wrong, not the code, so how can you expect anyone to write good tests if they don't have code to test the tests with? This will not work. People will get frustrated with the futility of writing half-assed code and will give up on UnitTesting, thinking that it doesn't work. The people writing the tests will not see the immediate benefits of writing tests, and they will not get a feel for what a good test is. The people writing the code will quickly run into the limitations of the tests and will see them as a roadblock rather than an engine.

See the AdoptingXpPatternLanguage, specifically AdoptUnitTests, for examples of how others have successfully adopted UnitTests.

Here's one quick idea for you. Let the manager have his/her way and split up the process. Then write your own UnitTests anyway without letting the manager know. It's easier to ask for forgiveness than it is to ask for permission. Make the tests work for you, put in some extra effort to get your code working properly. When other people get frustrated and complain, the manager will be strongly tempted to throw out tests altogether. That's when you show him your sparkling code and unit tests and say, "Oh, I thought we were supposed to add to the tests just like it says on WikiWiki."

Luckily, UnitTesting is one of the XP practices that is the easiest to get adopted because it has immediate quality and productivity results. The best pattern for adopting XP is AdoptUnitTestsFirst. It's your foot in the door. If you can prove that you can deliver results, it will tend to pave the way for further practices.

Unfortunately my ProjectManager is very sold already on the idea of XP but we need to take a bit of time to phase things in at the company. Companies move slowly and we need to make sure that XP doesn't get blamed for anything that is not it's fault. This being said, my ProjectManager has read ExtremeProgrammingExplained and is now moving on to ExtremeProgrammingInstalled. He also has a tendency to read magazine articles and pretty much anything that has the acronym XP in it. He still however is convinced about his approach to UnitTesting. I tried to explain to him the difference between AcceptanceTests and UnitTests but he's worried about people making mistakes. Neither of us wants to threaten the adoption of XP at our company. I feel however that by failing to follow a pattern (not a dogma) we may be shooting ourselves in the foot.

[From above: How can you write UnitTests for code you're not writing?]

The way he explained this to me is that one set of developers will write the code to test the public interface of unit that is to be coded. A second pair will then code the UnitTest itself. I think he is having difficulty because this sounds like it is exactly what XP says you should do. It sounds almost like it but not quite. In this case development is still driven by tests. It's just that your development is driven by someone else's testing. -- IainLowe

What if the tests are wrong? Most of them usually are on the first try. How do you refactor? If you're going to refactor, you need to be able to change the interface if it needs to change. What if a developer notices a condition that is obviously wrong, but passes all the tests?

I would still suggest writing your own tests as you program. You will soon see which method works best, and I have a strong gut feeling it will be to write tests as you program, not as a separate phase beforehand. Maybe you could suggest to the PM that one person in each pair is responsible for testing, the other for coding to pass the test (this is not the way PairProgramming is supposed to go, but if the PM is fixated on separating coding and testing, at least you can minimize the cycle time between finding a problem and fixing it). Then instead of having a separate phase so that four people can see the code, just switch partners more often. That way everyone will see all the code.

CategoryTesting