test driven development - Who should write the tests?

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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.

Answer 6

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.