Is it better to hire a developer to do unit tests, or to have each developer do their own?

Question

For a team of 10, is it better to hire an individual developer to do all unit tests, or to have each individual developer do unit tests for their own owned code?

Answer 1

It is essential that each developer writes unit tests!

Answer 2

Each individual developer should write their own unit tests -- only they know how the code is supposed to work, so only they will be able to write good tests for it. A developer that only writes tests won't be able to write tests for how the code should behave, but only for how it does -- in other words, useless.

Answer 3

The developer should test their own code. "Test first" or "Code first" is a different debate, but until you've tested your code (based on the documentation, NOT the implmentation), you can't be sure your implementation does what you think it does.

Answer 4

Everyone needs to test their own code. Period. Every developer must feel responsible for the quality of the product they are developing. I might consider hiring someone who has the specific job of reviewing the test cases covered by the unit tests with the developers to help them become better at covering all of the bases when testing their own code, but I would never consider telling a developer that writing the tests for his own code is someone else's job.

Answer 5

Every developer should be writing unit tests. If you have one developer writing all unit tests your other developers will probably write less maintainable code. Not to mention doing TDD is a great design activity. However, it may not be a bad practice to hire one developer as a QA type to write automated Integration tests.

Answer 6

It can be useful for developers to test each other's stuff but I think that is more of XP/pairing thing. Certainly, no developer should get a 'pass' from writing tests and no one developer should be writing tests exclusively.

Answer 7

If nothing else, there's no way that a single developer can keep up trying to write tests for 10 other developers. They'd have to be 10 times as fast as the rest of the team. Now, hiring some developers to do white-box integration, stress, and performance testing might make a of of sense. Even there, a 10-to-1 ratio is pretty extreme.

Unit Tests are supposed to be providing the developers with confidence that their code works correctly. If the folks writing the code aren't testing it, how do they even know if it's done?

Answer 8

Just concurring with the previous posts. A dedicated "unit tester" might have a hard time writing meaningful tests without changning the code.

Code written without the influence or knowledge of testing is likely to be much harder to test afterhand.

Answer 9

Have to disagree with the consensus.

You should do both

a) have your developers write their unit tests and

b) have a developer who reviews the documentation and extends any tests that do not deal adequately with the requirements expressed in the documention (i.e. range failures, outliers, exception handling)

Developers tend to look for the tests to express a positive ("it works") rather than disprove a negative ("it cant handle negative nubers").

Answer 10

The original question was not specific enough. There is a big difference between "doing" unit testing and "writing" unit tests.

Remember that a lot of the value of testing is in regression tests. Just because the "unit tests", whatever they may be in actuality, passed at some time doesn't mean that they will all pass today.

So in reality it would be better to have someone extra devoted to "doing" the unit tests, and providing a rigorous and durable test harness that would survive throughout continuing development cycles. He would have time to store the results in a database, report, etc. This would lead to a higher quality work flow no matter who came in later or who left from among the initial developers.

Answer 11

I'm gonna say that if you're writing the tests first the it doesn't matter. The tests will define the expected behavior and will also let you know when your code does what it's supposed to do.

That said, however, I'd have each developer write their own tests. In fact, I was taught that you don't write code until you have a test for it. But that's just me; I'm a really big TDD fan.

Answer 12

Noooo, you should not hire a developer to do unit test. It is every developer's responsibility to write test cases for code that he has written.

Moreover even if you think that you can ask a developer to write only unit tests, I think those unit test won't be good for any thing. To write a good unit test, developer needs to know what exactly that method is doning. Then only he can write +/- unit tests for a method.