There is a common practice in TDD to write a test before fix to avoid regression and simplify fixing. I just wonder what if the test and fix will be written by different people, total spent time will be almost the same but as now three people will think about possible failures (+tester) we increase probability that fix will cover all possible failure scenarios. Does this practice make sense or it will just waste additional time needed for one more person to familiarize with bug?


5 Answers 5


It is not necessary for the test and the code to be written by 2 distinct sets to achieve this.

TDD should be driven by ATDD (Acceptance tests) - the acceptance tests are written by customer/qa to ensure the solution is the right thing. To get them to pass, developers use TDD to develop the implementation. You could start off with a test-list on a piece of paper before getting to the keyboard (as Kent Beck suggests in his books). Also it is recommended to work in pairs, so that there is a higher chance of any slip-ups being detected earlier. If you want to involve a tester while coming up with the test-list that's fine too - however I believe developers should be thorough and able to identify all scenarios on their own.

All steps of TDD should be done by the same person/pair. Splitting up that work will increase need for communication / information loss. Writing tests is a non-trivial activity - the very act drives the design of your objects.

  • 2
    +1 for acceptance tests and ATDD. People always seem to forget about that when discussing TDD, and without acceptance testing of the customer's requirements TDD doesn't make much sense (we are writing software for the customer, after all). Jun 15, 2011 at 15:26
  • 1
    "TDD should be driven by ATDD (Acceptance tests)" Not necessarily. It may work for some people, but I wouldn't say that it's a requirement. Jun 15, 2011 at 17:02
  • @Rein - it isn't mandated.. but in general it works better when guided by Acceptance tests.. especially to maturing teams.
    – Gishu
    Jun 16, 2011 at 1:30

It sounds to me like you are describing http://en.wikipedia.org/wiki/Pair_programming#Ping_pong_pair_programming; a pair working on a feature alternates which member of the pair drives writing the test and implementing the code to make the test pass.

I've found it useful to make sure both members of the pair spend adequate time driving. It also helps reinforce knowledge sharing within the pair rather than allowing them to developer into a test specialist and an implementation specialist.


There is a belief out there that splitting up the developers and testers helps to create a better overall product, because the testers can help to "push" the developers by setting higher standards for them. Sometimes, developers will low-ball the quality of their test cases in order to keep themselves from having to fix edge-case bugs.

It probably comes down to how well your team works together. If they get along well, then the criticisms from the testers will likely be constructive. If the members do now work well together, the tension between the two groups will hinder the project. Testers might sabotage other members with ridiculous tests that make it appear that the developers are not meeting specifications (and the testers appear so brilliant for thinking of such a crazy test case).

  • 1
    On the other hand, sometimes developers will skimp on the quality of their tests because, "Well, if there's a problem, the testers will catch it." Jun 15, 2011 at 15:30

TDD involves a very short feedback cycle between test and code, on the order of seconds or minutes. The only way this would be feasible for different people is through ping pong pairing, as mentioned. There may be a benefit to splitting testing work between dev and test in other paradigms but with TDD it is simply not feasible. Fortunately, it's also not necessary.


This type of testing (unit tests) should be done by the same person/pair who actually writes the code.

The test execution is often integrated with compilation - so it perfectly makes sense that whomever is coding/compiling does this type of tests as well.

This type of unit tests are sometimes called programmers tests which kind of highlight who is supposed to write/execute them.

Your Answer

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

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