[Agile] [Patterns] Automated Developer Tests

See also.

Patterns are "discovered" and not "created."

-> A set of tests that are written and maintained by developers to reduce the cost of finding and fixing bugs - thereby improving code quality—and to enable the change of the design as requirements are addressed incrementally. Disciplined writing of tests encourages loosely coupled designs.
____________
- checking errors
- flexibility and program lifetime are improved - enable Refactoring.
- write your tests first and practiced Test-First Development
____________________

Context:
- needs to significantly improve its quality (reduce bug count)
- you decide to adopt Iterations and Simple Design
- build code using a distributed team - lack of communication
- practicing Collective Code Ownership

Forces:
- QA person and a developer must both find the bug and communicate via a tool to document the work being done
- bugs go back and forth between QA and development
- QA time to found, discovered, and fixed is greater then developer time to .... .
- Fixing one bug frequently causes another bug.
- Complex parts of the system tend to have more bugs than others
- Systems are designed to be general so that when requirements change the system can accommodate the changes.

Therefor:
- fixing bugs by finding them earlier: have developers test their code more rigorously
- automated testing
- test before checking
- document the change
- add a new test for a bug

- developers are more confident and courageous and will make design changes when needed relying on the tests that have been written to catch their mistakes.
- Read what others are writing

Adoption:
1. Commit as a team to the discipline of writing tests.
- Tests are just as important as production code
- Future complete it is only if tests are completed.
- Agree to be patient.
2. Find a tool that is easy to use. (examples: NUni, TestComplete)
- Use automatic testing tools as auxiliary testing and not the primary form of testing.
3. Treat your test code as you would your production code.
4. Try to get help:
- Bring in an experienced consultant
- Use other persons from your company that succeeded
- Read books
- Focused on TDD, Agile Development
5. Adopt Collective Code Ownership
6. Consider adopting Pair Programming
7. Start writing tests with the current Iteration
8. Within a few Iterations your team will come up against the problem of setup data
- Create a framework: Pull out the common setup code into common classes.
- Use Mocks and Stubs
9. Agree as a team on an approach and follow it.
10. Use Mock objects and Stubs to test classes that communicate with external systems.

But:
- It needs everyone on the team to be on board.
- The fact that tests are written says absolutely nothing about the quality of the production code. Adopt Pair Programming or performing regular code reviews on tests.
- Tests sometimes end up as second class citizens: we break all the rules of good design: Refactor it when the design is no longer adequate.
- Writing tests—especially for existing systems that have been written without testing in mind—is very hard.
- All tests should be running and passing all the time—no excuses.
- Code coverage becomes an overly important metric.