Unit Testing Standards

Practices

Name tests with the pattern similar to [Subject]_[Scenario]_[ExpectedResult] or something similar (for the backend, not frontend).
Organize tests by Arrange, Act, Assert
- First set up, or Arrange, what is needed for the test
- Then call the method, or Act
- Then Assert: make sure that the result is what you expect
Only one Assert per test method
- This makes it easier to see what went wrong at a glance
- This isn't a hard requirement, as multiple asserts may be needed for a specific test, but it should be the guideline.
Avoid test interdependence
- Each test should handle its own setup and teardown
Keep it short, sweet, and simple

A good unit test is:

Readable
- The intent of the test should be clear. A good test tells a story about some behavioral aspect of our application. Thus it should be easy to understand what scenario is being tested, and if it fails, easy to detect how to address the problem
Reliable
- Unit tests should only fail if there's a bug in the system under test. Good unit tests should be reproducible and independent from external factors such as the environment or the running order.
Fast
- Unit tests are written so that developers can repeatedly check them and check that no bugs have been introduced. If this testing takes a long time, developers are more likely to skip running them on their own machines.
Truly unit, not integration
- Both the unit test and the system under test should not access the network resources, databases, file system, etc., to eliminate the influence of external factors.
- Avoiding external resource access should also reduce the overall runtime of the tests.