## 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.