Unit testing best practices
- Independence: Ensure that each test is independent and does not rely on the results of other tests. This avoids introducing unintended side effects and keeps tests isolated.
- Isolation: Use mocks, stubs, or fakes to isolate the unit test from external dependencies. This allows us to focus solely on testing the behavior of the unit being tested.
- Readability: Write tests that are easy to read and understand. Simple and clear tests are more likely to reveal issues and are easier to maintain.
- Arrange-Act-Assert (AAA) Pattern: Follow the AAA pattern in test cases. Arrange the necessary preconditions, Act by invoking the tested function, and Assert the expected outcomes or behaviors.
- One Assertion per Test: Aim to have one assertion per test case. This keeps the test focused and makes it easier to identify which part of the test is failing.
- Descriptive Test Names: Use descriptive and meaningful test names. Well-named tests act as documentation, making it clear what behavior the test is verifying.
- Reproducibility:
- Good Test: A good test is reproducible, meaning that it consistently produces the same results when run multiple times under the same conditions.
- Bad Test: A bad test yields inconsistent results, making it difficult to determine the true outcome.
- Boundary and Edge Cases:
- Good Test: A good test includes boundary and edge cases, which are inputs or scenarios at the extreme ends of the spectrum. These tests can reveal vulnerabilities that typical cases might not expose.
- Bad Test: A bad test may focus solely on common cases, overlooking potential issues that could arise in less typical situations.
- Maintainability and Documentation:
- Good Test: A good test is well-documented, making it easy for others to understand and maintain in the future.
- Bad Test: A bad test lacks documentation, which can lead to confusion and difficulties in the long run.
- Efficiency:
- Good Test: A good test is efficient, meaning it runs quickly and doesn't waste unnecessary resources.
- Bad Test: A bad test may be inefficient, taking an excessively long time to execute or consuming excessive resources.
- Use good error messages, to know what failed if something is broken. Especially check response statuses before serializing something. Use soft asserts where needed.
Absence of redundant actions. Don’t do repeated check. Don’t do the things the test doesn’t need.
Balance between simplicity and complexity.
Use GOOD title naming.
QA automation best practices
- Defining automation strategy, so that everyone in the team understands this process. How, when and by whom tests are executed. Which environments are used for testing.
- Start testing early. Decompose big system into small parts, testable parts.
- Moreover, all members who write automated tests should follow the same pattern, make code reviews to each other. Naming conventions need to be discussed. Classes, test methods.
- Test cases prioritization. Create SMOKE, CRITICAL PATH, EXTENDED PATH test execution suites.
- Test data generation and usage? Will populate database and clean on a scheduled basis. Or use old data.
- Setting CI/CD with tests. Run tests regularly using scheduler on a daily or weekly basis on QA, DEV, PROD.
- Pay attention to test cases maintenance
- Reporting and logging, automatic metrics calculation, automatic bug report creation. Moreover if there any authorization, any user roles, handle this case. To achieve this you have to use right tools and frameworks. Whenever possible use cross-Browser and Cross-Platform Testing
- Use data-driven testing. Make your test data to be generated automatically.
- Tests should be independent from setup and teardown parts. You can use different implementations for these stages. Use try/except in teardown. Example: Disney.
- Practices
- ARRANGE ACT ASSERT CLEANUP
- GIVEN WHEN THEN