We test our components to ensure their quality and prevent unintended changes.
| Method | Description |
|---|---|
| Input | Test instructions. |
| Output | Pass/fail on the HTML-output of the test. |
| Principle | Check specific properties of a component. |
| Example | Does the button still have className .button-primary as expected? |
Unit tests are written using Vitest and React Testing Library. These tests run on every pull request.
All components must have their own unit tests, which are located in a separate file named component.test.tsx.
| Method | Description |
|---|---|
| Input | User interactions. |
| Output | Functional behaviour. |
| Principle | Custom functionality produces the same expected behaviour. |
| Example | Is the content visible when opening a accordion section? |
Not every component has interaction tests.
If a component includes custom interactive functionality, it must have an interaction test.
Interaction tests are located in the test story component.test.stories.tsx, within the play function of the story.
| Method | Description |
|---|---|
| Input | Variant of a component. |
| Output | Visual appearance of the component. |
| Principle | Find unintended changes to the visual output. |
| Example | Does the button still have a border? |
Each component must have its own visual tests.
The visual tests can be found in the test story component.test.stories.tsx, which should render all variants of the component.
| Method | Description |
|---|---|
| Input | WCAG Rules. |
| Output | Visual render of the component on which the rules are checked. |
| Principle | Make sure that there are no changes which worsen the accessibility of the component. |
| Example | Is the contrast still high enough? |
Accessibility tests are not configured on a component basis. The accessibility rules that the component should follow are the default ones from Storybook.
With each pull request there are two actions:
The interaction, visual, and accessibility tests are run by Chromatic. Chromatic runs these tests on each story labeled ‘Test’. If any changes are detected, they must be approved before merging the pull request. You can accept changes directly through the Chromatic dashboard. Once the changes are accepted, the pull request can be merged.
These actions are required to succeed before merging a pull-request.
Chromatic uses two tokens to run: a project ID and a secret token. The project ID is public within the repo, while the secret token is used in the workflow.
The secret is configured in two places: within the repo secrets and the Dependabot secrets. Since Dependabot does not have default access to repo secrets, separate secrets for Dependabot are configured on the Dependabot secrets configuration page.
Chromatic also uses a GitHub App to integrate with the repository. This app was installed by the enablement team, which is also part of our team within Chromatic. Occasionally, the enablement team may need to refresh the connection.
On every pull request, the workflow builds Storybook and publishes it to Chromatic, where the tests are run. The test status is displayed in the pull request through the app integration.
Ask a team member to add you to the Chromatic Team.