Testing best practices

We employ best practices to suggest how automated tests should look in the DigiDeps product. Best practices aren't hard-and-fast rules, but they are conditions we should aim to meet in every piece of work we introduce. These practices should be reviewed both during development and as part of peer review.

Unit tests

• Use unit tests where possible: not everything can (or should) be tested with unit tests, but you should endeavour to use them and to structure your code to support them as much as possible. That generally means writing small, self-explanatory, testable functions with no side effects.

Feature tests

• Set up test data within the test: rather than relying on the outcomes of previous tests, or loading state into the database directly, try to set up test data for your test within the test itself. This mean the test will be able to be run independently rather than having to be run as part of a whole suite.
  • You can also use data from fixtures (or add new fixtures to provide suitable data)
  • If you can't set up test data within the test, ensure it is created within the suite. Suites must be able to be run independently of each other
• Don't test Symfony features: The Symfony framework bundles have comprehensive tests and are used by millions of users. Try not to write tests which purely check that the Symfony framework is working as designed, but write tests to check our code.
• Don't duplicate tests: Avoid testing the same condition twice. Whilst it may be tempting to "re-check" something, it is a waste of resources if there's no chance of that condition having changed.

Test automation

• Run automated tests before merging to master: All tests are run on the master environment, but if they fail then it can clog up the CI pipeline. Reduce blockages by running tests on feature branches or locally before you merge.