Note, this document is about automated tests and checks. Manual testing is beyond the scope of this document, and somewhat exists outside of the lifecycle of this code base. We regard the human evaluation of the subjective experience of our apps as vital, as well as appreciating the irreplaceable value of human exploratory testing.
All of our automation, including automated checks, are events driven. Diagram 1. shows the current key events.
Diagram 1. The key events driving automated checks and tests in this repository. Note that preview and production deployments trigger the same deployment status checks.
- Prettier
- ESlint
- Stylelint
We use Jest, with the NextJS Jest Config.
npm run testwill run the tests using--watchnpm run test:ciwill run the tests once and create a coverage report.
Unit tests only for now. Please write any tests dependent on a network connection, a database, filesystem or any other IO. They all run for each commit and we need to keep that fast.
- Manually with
npm run test. - On pre-commit.
- On push in a Github workflow.
Tests live next to the code they are testing wherever possible. Next does not allow any files under the src/pages/ directory other than routes, so those test file are under the src/__tests_/pages/ directory, mirroring the src/pages file structure.
Logic tests and snapshot tests should be in different files because their "failure" state has a different meaning. Snapshot tests should live next to the component they are testing, and have a name following the pattern <component_name>.snapshot.test.tsx.
The current tests live here. The naming is intended to leave room for creating some product-facing tests using feature files, this is subject to change.
- Design and engineering inspection of components in isolation, including a11y checks.
Visual regression testing of deployed apps.
In a Github workflow triggered by a deployment_status === success event.
Accessibility testing of deployed apps.
In a Github workflow triggered by a deployment_status === success event.