Question

Is it better if one person is responsible for writing tests and another for fulfilling them or should the coder and test writer be the same person, ideally?

Answer 1

Unit testing is something you do as you’re writing code. This testing is testing your view how things should work (on the level of class/method/algorithm) and it supports you when developing as you can run through the tests before and after making changes to see that things are still according to the tests you have in place. See this as something that will aid the programmer as he/she works. Further, the tests will also provide a way to see how something is supposed to work for anyone looking at the code. TDD (Test-Driven Development) is not changing this concept, rather highlighting that the one coding needs to first think how it should work and what to expect.

If there is a problem with not seeing own problems one can try pair-programming, code reviews or other ways to look at things with more eyes and brains. Still I strongly believe unit testing is a tool for the programmer and not something done by anyone else.

Coming to other types of testing, like integration testing, functional testing or even (system) performance testing, it might be good to have other people doing this. Especially if you want to automate this testing it requires you to know how to do things and also maybe a higher level of business knowledge on what to test and how.

The answer to your question also depends on the culture and how your organization works, however, I believe you in all cases want to do unit testing as part of developing code. If this results in problems, there might be something else which is broken in the organization or something which needs to be looked at.

Update

Here are a few things I’ve seen in organizations which affect unit testing practices:

• some people might not want to write unit tests;
• some people might not know how to write good unit tests, which can undermine the benefits of doing it and that might be used as a “proof” that unit testing is bad;
• the organization might not bring people to work together, rather have distinct responsibilities such as coders code, testers test etc., which might force unit testing on someone;
• some people might be hired to write unit tests, so if this role is not changed it contradicts writing unit tests as you code;
• there might be a very small organization which can mean implicitly that everyone does a bit of everything;
• the organization as a whole does not acknowledge the benefits of unit testing, but rather code-as-quick-as-possible-and-deal-with-problems-later,
• who is driving the effort to do unit testing? Is it one person? Developers? Management?
• is the organization free to decide itself who does unit testing?

If there is an agreement to have unit testing, the above things might be issues to deal with in order to bring the organization into a state where things just work out naturally. If you have people with good unit testing practices and experience, let them lead things to bring the rest of the team to see the magic of unit testing.

Personally, I believe that if people see the benefits of unit testing, can write good unit tests, automate them with builds, and if the team can decide themselves how to organize how to get the unit tests written it will all fall naturally into place so that developers write unit tests while developing code, anyone can at any point add more unit tests for any code they’re looking at. If there are testers, they would focus on other types of testing like functional testing or exploratory testing.