Dev: Testing

We use 2 main kinds of tests:

Unit Tests

Goal: test the code in a PR in isolation.

Techniques:

For new files, or files without a unit test, setup .test.js or .test.jsx files even if you don't add any unit tests. But you should add some unit tests ;). I.e. just always do unit tests.. we need a place to put test fixes when we find them.
Test input/output pairs for pure functions.
For code with complex dependencies, mock the environment, and then test using the same approaches as above.

Key Mock files using Jest (our testing framework):

any directory can have mocks for sub-dirs by defining them in mocks directory. See e.g.:
- Share/mocks/web-ifc-viewer.js where we mock the entire three + IFCjs stack
- Share/src/mocks where we mock:
  - Auth
  - Network APIs, e.g. GitHub with Mock Service Workers (msw)

Goal: Ensure our functional requirements are validated as running in prod.

Techniques:

Each UX story should have a cypress test file in cypress/.... Each UX task should have one or more test cases.
Run cypress in local headed mode to see it step through UI actions. Very useful for complex debugging.

Cypress tests are slow. To speed up running them, we run many in parallel in subprocesses using a bash script, with an alias in our pkg scripts.

This should speed up tests from many minutes to less than a minute.

yarn cy-parallel

We use the Percy extension for cypress to record UI state to validate UX requirements after a sequence of actions.

Running percy tests is currently restricted to Bldrs staff as it's a paid service. Please ask if you'd like quota to run them.

Results look like this, from a PR that yielded a new cypress percy snapshot:

Current testing targets:

APIs we use:

From caniuse.com for "webgl" (Feb 2024):