[ACCEPTED]-Who should write tests?-tdd

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

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

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

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

Update

Here are a few things I've 13 seen in organizations which affect unit 12 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 11 to have unit testing, the above things might 10 be issues to deal with in order to bring 9 the organization into a state where things 8 just work out naturally. If you have people with good unit testing practices and experience, let 7 them lead things to bring the rest of the team to see the magic of unit testing.

Personally, I believe that if people 6 see the benefits of unit testing, can write 5 good unit tests, automate them with builds, and 4 if the team can decide themselves how to 3 organize how to get the unit tests written 2 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 1 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 45 answers, some based on how organisations 44 work, some based on qualifications for planning 43 and testing. There are many different ways 42 to organise testing, especially since organisation 41 sizes differ and may or may not have resources 40 to hire different teams.

There are different 39 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 38 of functionality in isolation e.g. a single 37 controller action) and Integration testing (those atoms working 36 together e.g. a controller working with 35 the domain tier objects, domain tier objects 34 working with data tier objects,) should 33 be done by the developer.

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

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

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

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

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

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

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

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

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

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

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

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

An informal policy in my development team 12 is

Everyone does everything.

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

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

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