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?
Tell me more
×
Programmers Stack Exchange is a question and answer site for
professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.
|
|
||||
|
|
migrated from stackoverflow.com Jun 15 '11 at 2:59
|
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. |
|||||||||||||
|
|
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). |
|||||
|
|
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. |
|||
|
|
