Your question is orthogonal to your problem. Sticking two programmers that don’t want to or can’t write good unit tests together isn’t going to get you more/better unit tests.

Sticking a programmer who is poor at writing unit tests with one that is good might propogate good habits, but might not be a good pair for other reasons (unit testing is only a part of the entire development process after all). There are other questions/posts that deal with pair programming’s benefits and problems.

Your goal should be to change the culture that caused the problem in the first place. Well done pair programming can help that, but it will usually require a combination of things all pushing towards that end goal. There is no silver bullet (pun intended) for making people write good unit tests.

From my personal experience as a team member which has gone through a similar process, the choice of pair-programming and TDD was very successful and useful. Our coverage has increased significantly.

What we did was:

• force pairs for production code. No code was allowed to be committed if not created in pairs.
• force TDD, no code was allowed to be committed if not TDDed.

It was hard and slow at first (a few weeks, about a month and a half), but than it became very practical and natural.

EDIT: Naturally we had very high code coverage an new code, and we refactored old code and added test to it slowly. When an old class / module had to be modified, we added tests and modifications. Gradually coverage became pretty good at the level of the whole project.

Finally, after we were used to both processes, the mandatory nature of the 2 processes was removed and now we pare naturally most of the time (about 90%) but we also commit simple stuff made single or without TDD.

There’s easier way to achieve higher coverage. Simply make a rule that no code is allowed to be committed unless it is covered by sufficient amount of tests (what sufficient means is another story though). Of course pair programming might help, but there’s no guarantee that when your pair consists of two test-reluctant people, they will suddenly produce test-heavy code (I’d even say it’s highly likely they’ll stick to their test-reluctance together).

For the record, forcing people to write tests might result in very poor tests, which is opposite to what you want to achieve. I think it might be good idea to pre-assign pairs, ie. test-aware person with test-reluctant person, so the former can help out and explain why things are being dealt with in a certain way to the later.

If your projects are big, a separate test team is the way to go. Most big software firms have separate test teams.

Pair programming does improve the quality of the code, but it has one big potential problem: most managers don’t like it and will try no prevent it. They think they are paying two people to do the work of one.

Edit after reading @Giorgio ‘s comment:

“You should not test your own code”, that’s true. Working knowing that other people will test, means you have to programm according to accepted standards. No “I understand my own mess” kind of logic.

In fact, Pair Programming will not help you. The main benefit of pair programming is to spread or combine knowledge to solve some problems.

The test “discipline” is a huge new universe. We have a lot of approaches to do testing, and it is a long time process. If your company does not have time, money, and employers to implement a good test process, an external testing team can be the viable solution.

If you know your unit test coverage is low you must be be using a coverage tool in the first place. Why don’t you just target the pieces of code it hightlights and write unit tests for them?