Who should write tests?

Is it better if one person is resp开发者_高级运维onsible for writing tests and another for fulfilling them or should the coder and test writer be the same person, ideally?

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.

This question will invite many different answers, some based on how organisations work, some based on qualifications for planning and testing. There are many different ways to organise testing, especially since organisation sizes differ and may or may not have resources to hire different teams.

There are different types of testing:

• Unit Testing
• Integration Testing
• Functional Testing
• Non-Functional Testing - stress, penetration and many other types
• User Acceptance Testing

In my experience:
Unit testing (atoms of functionality in isolation e.g. a single controller action) and Integration testing (those atoms working together e.g. a controller working with the domain tier objects, domain tier objects working with data tier objects,) should be done by the developer.

Functional testing (system functions as the spec states) should be done by a separate QA team.

Non-Functional testing can be done by a QA team or architect/tech lead.

UAT (system is fit for purpose) should be done by the client.

The reasoning behind this is, as automated Unit and Integration testing are white box (you can see inside the application e.g. the code), they will need to be completed by a developer (not neccessarily the developer responsible for the code under test).
Functional testing and UAT are black box (you can't see inside the application) so are more likely to be done by someone non-technical, but skilled in test analysis.
Non-functional testing can be either black or white box depending on what's under test and the overall strategy.

It's important to note that more defects are found by testing another's work than testing your own. The tester will think differently and so look for/try things that would not have been accounted for during development, and people are naturally protective of their code (no matter how hard one tries to be objective).

If there isn't a seperate test team, it's good to have developers test each others' code.

To answer your question a bit more, when I was a tester I was responsible for test analysis (deciding what functional tests were required to test the specs) and writing test scripts and manually executing them tests. Once those scripts were written, any tester could execute them, but it was important that the test analysis was done separately to the developer's work on the application.

With TDD the developing unit (read a programmer or pair) should write the tests.

TDD (Test driven development) -unit tests are typically at a technical level. The developing unit should write them as they come to implement the class. The issue you may run into if others write the tests is that the external force will influence the design. TDD works well when the developers are doing the design.

With BDD/ATDD the QA/PO should be involved.

BDD(Behaviour driven development) and ATDD(Acceptance test driven development) tests are typically written at a less granular level. The better tests are written with the stakeholder in mind. So the better people to write these are QAs (Quality Assurance), POs(Product Owners) or BAs (Business Analysts). That's not to say a developer cannot write them you just need to step into that role.

The beauty of working in pairs is that if your pair writes the tests, there is an automatic sanity check of the tests as they are written.

An informal policy in my development team is

Everyone does everything.

That is, there are no Testers, Programmers or Architects. Everyone is expected to do a bit of all the activities.

This is to avoid a waterfall process. If an activity is the sole preserve of one person, development can become sequentialized, with people handling work down the line and being unaware of the full consequences of the decisions they take.

This does not mean everyone works on every task simultaneously. It means each person works on each kind of task at some point in time