Unit Testing Guidelines - geosoft
- Keep unit tests small and fast
- Unit tests should be fully automated and non-interactive
- Make unit tests simple to run
- Measure the tests
- Fix failing tests immediately
- Each developer should be responsible for making sure a new test runs successfully upon check in, and that all existing tests runs successfully upon code check in.
- Keep testing at unit level
- Start off simple
- Keep tests independent
- Keep tests close to the class being tested
- Name tests properly
- Test public API
- Think black-box
- Think white-box
- Test the trivial cases too
- Trivial is hard to define. It may mean different things to different people.
- From a black-box perspective there is no way to know which part of the code is trivial.
- The trivial cases can contain errors too, often as a result of copy-paste operations:
- Focus on execution coverage first
- Cover boundary cases
- Provide a random generator
- When the boundary cases are covered, a simple way to improve test coverage further is to generate random parameters so that the tests can be executed with different input every time.
- To achieve this, provide a simple utility class that generates random values of the base types like doubles, integers, strings, dates etc. The generator should produce values from the entire domain of each type.
- Test each feature once
- Use explicit asserts
- Always prefer assertEquals(a, b) to assertTrue(a == b)
- Provide negative tests
- Design code with testing in mind
- Don’t connect to predefined external resources
- Know the cost of testing
- Not writing unit tests is costly, but writing unit tests is costly too
- Prioritize testing
- Unit testing is a typical bottom-up process, and if there is not enough resources to test all parts of a system priority should be put on the lower levels first.
- Prepare test code for failures
- Write tests to reproduce bugs
- Know the limitations
- Unit tests can never prove the correctness of code!!
Apr 04, 2012
comments powered by Disqus