add basic frontend tests with Vitest + React Testing Library #1873
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
closes #1334
main
branchOverview
Note that this PR is missing one of the issue's action items; it does not set up a GitHub Action to block merging until tests pass. That effort should be part of a separate PR, and the example tests here are trivial enough that it won't hurt very much if we lack those status checks for some time.
Since I soon won't be available to contribute to this project further, I've braindumped some info about testing in contributing.md (for more objective info) and in this PR comment (for my opinions). I hope it's helpful! 🙏🏽
On code coverage
Several of the issue's action items mention code coverage. IMO code coverage is a more helpful metric when testing backend code or a library. We should de-emphasize coverage when it comes to frontend testing, because testing all of an app's UI state is difficult to account for even with 100% frontend test coverage (citation needed).
Additional resources
Both React Testing Library's and Redux's docs agree that the most valuable tests we can write are tests that most closely resemble how users interact with our software. These would be end-to-end (e2e) tests, which simulate complete user flows.
To write e2e tests, we need to work with the UX design team to define what all of our critical user flows are. For example,
These definitions will help us determine what UIs/components we need to test, and what assertions we need to make about them.
e2e tests can be run with a tool like Playwright, which is recommended by Kent C. Dodds, creator of React Testing Library. But it's also possible to run comprehensive e2e tests with just Vitest and/or React Testing Library. A great example is Excalidraw, an open-source React app whose UI is also primarily canvas-based. The challenge of testing canvas-based UIs is that UI tests make assertions about DOM node properties (whether an element is visible, what text it contains, etc.); however, canvas interactions generally don't update the
<canvas>
element. Here's one example of how Excalidraw makes assertions about app state--we could do something similar by making assertions about 311-Data's Redux store.Excalidraw also has GitHub Actions set up to run tests as status checks on PRs.