Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
F.I.R.S.T Principles of Unit Testing
Clone this wiki locally
FAST, ISOLATED/INDEPENDENT, REPEATABLE, SELF-VALIDATING and THOROUGH/TIMELY
- A developer should not hesitate to run the tests as they are slow.
- All of these including setup, the actual test and tear down should execute really fast (milliseconds) as you may have thousands of tests in your entire project.
- A test method should do the 3 As => Arrange, Act, Assert
- Arrange: The data used in a test should not depend on the environment in which the test is running. All the data needed for a test should be arranged as part of the test.
- Act: Invoke the actual method under test.
- Assert: A test method should test for a single logical outcome, implying that typically there
should be only a single logical assert. A logical assert could have multiple physical asserts as
long as all the asserts test the state of a single object. In a few cases, an action can update
- Avoid doing asserts in the Arrange part, let it throw exceptions and your test will still fail.
- No order-of-run dependency. They should pass or fail the same way in suite or when run individually.
- Do not do any more actions after the assert statement(s), preferably single logical assert.
- A test method should NOT depend on any data in the environment/instance in which it is running.
- Deterministic results - should yield the same results every time and at every location where they run.
No dependency on date/time or random functions output.
- Each test should setup or arrange it's own data.
What if a set of tests need some common data? Use Data Helper classes that can setup this data for re-usability.
- No manual inspection required to check whether the test has passed or failed.
Thorough and Timely
- Should cover every use case scenario and NOT just aim for 100% coverage.
- Should try to aim for Test Driven Development (TDD) so that code does not need re-factoring later.