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?

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 McIverJan 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.

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 McIverJan 11 '11 at 15:00

1

+1: The third paragraph makes a good point.
–
Larry ColemanJan 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 SheararJan 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.

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.

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.

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.