Skip to main content

How We Test

Type: ReferenceCreated: Team: Platform
draft

Running the tests​

Run the tests locally before you push — it's the quickest way to catch a break.

Frontend (from the frontend folder):

npm run test

Two more that come in handy:

  • npm run test:coverage — the same tests, plus a coverage report written to frontend/coverage.
  • npm run test-all — runs formatting and lint checks alongside the tests, so you can check everything a PR needs in one command.

Backend (from the backend folder):

mvn test

Where tests live​

  • Frontend — tests sit next to the code they cover, named after the file with a .test.tsx ending. For a component at …/EmojiChip/EmojiChip.tsx, the test is …/EmojiChip/EmojiChip.test.tsx. They run on Jest in a browser-like environment.
  • Backend — tests live under backend/src/test/java, mirroring the package layout of the code they cover. A test class ends in Test for a unit test or IntegrationTest for one that wires more of the app together.

If you're adding a test, follow the pattern of the tests already next to the code you're changing.

Writing tests for your change​

Add or update tests to cover what you change. If you add behaviour, add a test for it; if you change behaviour, update the tests that cover it. Reviewers look for this, and the PR template asks you to confirm you've written adequate test cases.

What CI runs for you, and what it doesn't​

Some tests run automatically; the rest are on you.

  • Backend tests run on every pull request. CI runs mvn test and saves the test reports as a downloadable artifact, so a backend test that fails shows up in the PR without anyone running it by hand.
  • Frontend tests do not run in CI. The frontend pipeline builds the app to catch build errors, but it does not run the Jest tests. So run the frontend tests yourself before you push — nothing downstream will catch a failing one for you.