## Guidelines for writing test cases
These guidelines are for writing more effective, informative, and useful test cases.
### Writing new tests
- New test methods should be written for new features introduced, as well as for any bugs fixed, to prevent regressions.
- Test methods should be kept short, and oriented around a single unit of functionality; a good length is 20 assertions or fewer, _or_ 12 or fewer queries against the subject under test _if_ multiple assertions are being issued against a single query.
- Test methods should always be given a descriptive name, and have a docblock clearly explaining the functionality or intended behavior that the test method asserts. Include `@link` attributes to tickets where appropriate.
### Existing tests
- Between releases, existing test methods should never be changed or added to, except to update or remove code to maintain consistency with modified or deprecated functionality.
### Effective test cases
- Tests should be written directly against the subject class, and focus exclusively on the subject's code, not dependencies or externalities.
- Tests should be written to verify exactly what should have changed in the application's state, in the course of the subject method itself (where applicable).
- Insofar as is reasonably possible, tests should also verify that nothing within or affected by the method's scope changed that should not have.
