Take the 2-minute tour ×
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.

Originally, it is the duty of the developer to write the test, but I noticed that in many cases/e-mature developers those cases are not giving even 80% coverage.
How about I have a QA person dedicated to write ALL the tests for a given project instead of the developer?
Are there any cons to that?

share|improve this question
Keep in mind that TDD does NOT mean write all the tests for all the code then write the code. It is a term; yet the practical approach is writing tests and then writing code in small iterations; approaching it in a more parallel manner. Writing ALL the tests ahead of time is a waste of time as refactoring will inevitably surface. –  Aaron McIver Jan 11 '11 at 14:58

6 Answers 6

In Test-Driven Development, the tests must be written by the developer. Otherwise someone other than the developer is driving the development.

So as soon as you give the job of writing tests to a non-developer, that person becomes a developer.

My experience in TDD is that writing the test code is ofter as hard as writing the production code. So if you have resources capable of writing good unit test / integration test code, they ought to be writing the production code that makes those tests pass.

share|improve this answer
If you had two like minded individuals from a skill-set stance you could arguably approach TDD in a pair programming manner swapping off/on between tests and code. Call them testers/programmers/code monkeys...it is about one's skill set as you touched on. –  Aaron McIver Jan 11 '11 at 15:00
+1: The third paragraph makes a good point. –  Larry Coleman Jan 11 '11 at 15:25
And given that you write_test-write_code-run_test possibly every minute you would annihilate your rate of progress. –  Frank Shearar Jan 11 '11 at 17:36

QA's job is to perform entirely different kind of test (i.e. usability/integration testing). They don't really have to know the technologies used in the code.

If you're worried about low code coverage, you need to discipline your developers. For example stopping work on any new features, until code coverage increases. Some organisation go as far as having a pre-commit hook on their repository that will not allow checking-in uncovered code.

Last but not least, in 'pure' TTD, there should be no uncovered code at all (since you write tests first). However there are cases (although people argue about it) where lower code coverage is acceptable. Some argue for example, that writing tests for getters/setters of POJOs is a waste of time.

share|improve this answer

those cases are not giving even 80% coverage

That could be a management problem.

Or it could be irrelevant.

First, the difference between 80% and 100% coverage is probably a lot of cost for very little benefit.

"Coverage" can mean anything. Lines of code, logic paths, etc. I'm guessing you mean lines of code (not logic paths).

Some logic paths are pretty well tested "by inspection". The code is obvious, has no if-statements, has a very, very low complexity, and probably doesn't need an additional test.

20% more tests isn't always 20% more quality.

Second. It's a management problem. If management wants 100% coverage, they have to put a reward system in place that rewards 100% coverage instead of "good enough to release" 80% coverage.

Adding QA folks to write more tests won't help much.

Adding developers to write more tests is what will be required to get to 100% test coverage.

share|improve this answer
Who said anything about 100% coverage? –  Eric Wilson Jan 11 '11 at 14:51
@FarmBoy: The question implies that 80% coverage isn't good enough. What is good enough? The usual magical number is 100% coverage. –  S.Lott Jan 11 '11 at 14:55
But my coach always told me to give 110%. Why can't I require that amount of coverage... ;-P –  Berin Loritsch Jan 11 '11 at 14:59
@Berin Loritsch: I'm behind you 200%. –  S.Lott Jan 11 '11 at 15:00
@Job: "Some QA folks can write some code". Right. Then they become developers, which is a good thing. –  S.Lott Jan 11 '11 at 15:26

IMHO Unit testing isn't a QA process. It's more about speeding up development (by shrinking the feed back loop for developers). It should be done by the person writing the component (aka unit) with a focus on the components usage (by another developer).

Functional testing is a QA process that can and should be done by a QA team. These can be done by the developer but a non developer would be better as the developer might not know all the ways a user might use the application.

Both can be done in a TDD fashion.

share|improve this answer

TDD is not just about testing, but is also about design. Writing code just to pass the tests usually leads to smaller and maintainable code. If you delegate any other person to write the tests, you'll also be delegating the responsability of creating good code.

You should also note that the coverage will not tell you about the code quality and will not tell you if the domain rules are being covered.

share|improve this answer

If you need at least 80% coverage, then you need to do a couple things:

  • Provide your developers the tools they need to determine what level of coverage they do have--and make sure it's apples to apples. There's more than one way to measure coverage.
  • Provide a reward/incentive for accomplishing that feat. Programmers are only going to do what they feel will pay off. If 50% coverage is good enough to ensure quality and get all the work done, that's what they will do.

Finally, understand that there is a difference between intended execution paths and unintended execution paths. In the process of writing test driven code, you may have proven that you need a pair of independent if statements. As a result there are tests for two of the potential four execution paths available. Add one more independent if statement, and you have a potential for eight execution paths (i.e. it's going up exponentially).

Understand that TDD does not necessarily predict every potential path of execution, so there are a number of tests that might need to be written to be complete but aren't written because there wasn't a need to test that path. In short, TDD doesn't guarantee coverage, but it does guarantee that there is at least one test to prove the reason d'eter for the code that does exist.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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