We run a project in which we want to solve with test driven development. I thought about some questions that came up when initiating the project. One question was: Who should write the unit-test for a feature? Should the unit-test be written by the feature-implementing programmer? Or should the unit test be written by another programmer, who defines what a method should do and the feature-implementing programmer implements the method until the tests runs?
If I understand the concept of TDD in the right way, the feature-implementing programmer has to write the test by himself, because TDD is procedure with mini-iterations. So it would be too complex to have the tests written by another programmer?
What would you say? Should the tests in TDD be written by the programmer himself or should another programmer write the tests that describes what a method can do?
views:
176answers:
8The Unit Test should be written prior to coding and test that a Unit meets the requirements, therefore it should be fine for the developer implementing the code to also write the Unit Test.
In TDD the developer first writes the unit tests that fail and then fixes the production code to make the test pass. The idea is that the changes are made in really small steps - so you write a test that calls a method that doesn't exist, then you fix the test by adding an empty method, then you add some assertion to the test about the method so it fails again, then you implement the first cut of the method, etc. Because these steps are so small it is not practical to have a separate person write the tests. On the other hand I would recommend pairing, so that you gain some additional eyeballs making sure the code makes sense.
I think it would be possible to have another person/team/or even client (when you use tools like Fitness) to write acceptance tests, that test the whole functionality on a higher level.
One of the benefits of TDD is the fast feedback cycle. Having another developer write the tests would slow the process down too much. The same developer should write both.
It could be done both ways, you could write the unit test yourself, or go for the ping pong approach where you take turns with another developer writing unit tests and writing the implementation if you are pairing. The right solution is the one that works for you and your team. I prefer to write the test myself, but I know others that have had luck with the ping pong approach as well.
Per Justin's response, not only is it fine for the implementing developer to write the test, it's the de facto standard. It is, theoretically, also acceptable for another programmer to write the test. I have toyed with the idea of a "test" programmer supporting a "feature" developer, but I have not encountered examples.
If I write a test for an object, in addition to the inputs and outputs I expect, I have to know the interface it exposes. In other words, the classes and methods under test must be decided upon before development begins. In twelve years I have only once worked in a shop that achieved that granularity of design before development began. I am not sure what your experiences have been, but it doesn't seem very Agile to me.
I'm a little confused here.
You say that you want to use TDD and you do seem to understand it correctly that a programmer writes a test, then the same programmer writes the implementation and does it in the next few seconds/minutes after writing the test. That is part of the definition of TDD. (btw 'the same programmer' also means 'the other programmer in the pair' when practising pair programming).
If you want to do something different, then go for it and write up your experiences in a blog or article.
What you shouldn't do is to say that what you do different is TDD.
The reason for 'the same programmer' writing the implementation, and writing it very soon after the test is for the purposes of rapid feedback, to discover how to write good tests, how to design software well and how to write good implementations.
Please see The Three Rules Of Tdd.
Unit Tests and Acceptance Tests are two different things, both of which can (and should) be done in TDD. Unit Tests are written from the standpoint of the developer, to make sure that the code is doing what she expects it to. Acceptance Tests are written from the standpoint of the customer, to make sure the code fulfills the appropriate need. It can make a lot of sense for the Acceptance Tests to be written by someone else (usually because it requires a slightly different mindset and domain knowledge, and because they can be done in parallel) but Unit Tests should be written by the developer.
TDD also says that you shouldn't write any code except in response to a failing test, so having to wait for someone else to write the Unit Tests seems pretty inefficient.