4

My team follows the Scrum development cycle. We have received feedback that our unit testing coverage is not very good.

A team member is suggesting the addition of an external testing team to assist the core team, but I feel this will backfire in a bad way.

I am thinking of suggesting pair programming approach. I have a feeling that this should help the code be more "test-worthy" and soon the team can move to test driven development!

What are the potential problems that might arise out of pair programming??

Improve this question
8
  • 7
    One potential problem with pair programming is that most managers don't like it. They think they are paying two people to do the work of one.
    – Tulains Córdova
    Oct 17, 2012 at 14:16
  • 1
    @user1598390, Managers are my last concern. For the moment let us assume the ideal scenario where everyone supports the "best" solution with out any ego issues.
    – TheSilverBullet
    Oct 17, 2012 at 14:30
  • Pair programming can be good for spreading knowledge about the code, but can slow down development (especially of experienced programmers) by focusing too much on irrelevant details.
    – Giorgio
    Oct 17, 2012 at 14:34
  • 2
    what do you currently do for code reviews? (pair programming is code reviews @11)
    – jk.
    Oct 17, 2012 at 14:38
  • @Jk, As far as I know, there is no code review happening...
    – TheSilverBullet
    Oct 17, 2012 at 18:22

6 Answers 6

Reset to default
9

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.

Improve this answer
5
  • Well, I am suggesting pair programming as opposed to an independent unit test team...
    – TheSilverBullet
    Oct 17, 2012 at 16:50
  • 3
    @TheSilverBullet - anything is better than assigning developers dedicated to writing unit tests...
    – Telastyn
    Oct 17, 2012 at 17:25
  • Why would you say that? What are the potential hazards of dedicated unit test team? This will help me in presenting my case...
    – TheSilverBullet
    Oct 17, 2012 at 18:20
  • 2
    @TheSilverBullet - Even if developers see the usefulness in unit tests, or are good at writing them... they don't want to do that as a full time job. If they did, they'd be in QA. Removing all of the creativity from the job is a quick and easy way to push your developers into finding new jobs.
    – Telastyn
    Oct 17, 2012 at 18:29
  • Thank you for your perspective. This discussion really helped. I am sorry for the delay in accepting your answer.
    – TheSilverBullet
    Nov 12, 2012 at 8:37
6

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.

Improve this answer
2

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.

Improve this answer
1
  • Yes... Instead of having a separate testing team, my suggestion was to pair a tester with a developer... As suggested by you.
    – TheSilverBullet
    Oct 17, 2012 at 16:53
0

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.

Improve this answer
6
  • But separate test teams will never converge in implementation of TDD which I what I aim for...
    – TheSilverBullet
    Oct 17, 2012 at 14:31
  • 1
    +1. I would add that (1) pair programming does not always work and can in some cases decrease productivity instead of increasing it and (2) as you stated, unit tests cannot replace a test team that is disjoint from the development team (you should not test your own code) and that verifies the application according to a well-structured protocol.
    – Giorgio
    Oct 17, 2012 at 14:33
  • 3
    Most large software houses have manual testers and automated tests teams. But I have never seen separate team for unit tests, as those are programmer-only tests, wrote by the very same guys who write code.
    – k.m
    Oct 17, 2012 at 14:44
  • @user1598390 I am specifically talking about unit tests... There is already an independent testing team for the other purposes
    – TheSilverBullet
    Oct 17, 2012 at 16:51
  • 1
    "... means you have to programm according to accepted standards": In my experience there is more to it: someone who's not implemented the program is going to use it in many ways you hadn't thought of: each developer will spontaneously use his / her software the way they think it should work. On the other hand, someone else might come up with weird ways of using the program making it easier to expose bugs.
    – Giorgio
    Oct 17, 2012 at 18:17
0

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.

Improve this answer
0

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?

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.