These guidelines are a work in progress. While most of this document should be treated as suggestions, there is one concept that should not be broken:
State should not be shared between tests. The order tests are executed should not impact the outcome of individual tests.
Without this guarantee, tests cannot be run in parallel, and modifications to an individual test could impact the entire suite. There is almost always a design modification that can be made to avoid this being necessary.
The rest are guidelines and not absolutes. There are exceptions to every rule, and they can be discussed during code review.
- Tests should test one concept at a time. Avoid asserting things that are not related to that concept.
- Tests should be relatively short (<= 15 lines). Complex setup should take place in fixtures or supporting libraries.
- Use concepts like data-driven tests to avoid having to repeat blocks of test code. As a rule of thumb, repeating blocks of code more than 2-3 times is enough to warrant using data-driven tests.
- Give test code the same level of care you would application code. For example, use meaningful variable names and refactor common logic to supporting libraries.
- The purpose of any given test should be clear. Write each test assuming a new team member will see it next.
- Tests should focus on outcomes. How the result was achieved is less important and is something that may change over time.
- Try to make a new test fail at least once to assure the test is testing the behavior you expect correctly.
- Using a timed sleep/wait in tests is strongly discouraged. There is often an alternative solution that allows the test to instead wait for some change in state.
- Avoid "magic strings" in tests. URLs, credentials, and other common data should be stored in configuration.
- Prefer enums to strings in cases where a value represents a type or option.