Overview

We test our code under services/remix in 2 ways:

  • Unit/Integration tests
  • E2E tests

Our general approach is the following:

  • write unit/integration tests for each new feature we add, and ensure these tests cover both happy and negative flows. Since these tests don’t run against a real server, we utilize mocks to simulate API calls / external services and dependencies. These tests run for each PR commit that has changes under services/remix, which means the feedback loop from these tests is very fast, and the bulk of our tests should be written here.
  • write E2E tests for important user flows and logic that can’t be tested with unit/integration tests. Since E2E tests run against a real server (meaning they require a lengthy setup process), and since they are slower to run and only run in the deploy pipeline, we should aim that our E2E tests are not bloated, by ensuring they cover only happy flows.

Both can be run locally - see the sections below for more information.

Unit/Integration tests

We use Vitest, MSW and React Testing Library to test our code.

Run the unit tests with the command npm run test.

There are many different use cases for unit/integration tests:

  • Test functions purely, not as part of a component
  • Test the actual HTML content that’s rendered in the DOM
  • Test happy flows and negative flows by mocking API calls or other external dependencies
  • Test only specific parts/pages of the application
  • etc.

Some general notes:

  • Unit test files should sit next to the files they test, and have the suffix .test.ts(x) (.tsx if it checks React, otherwise .ts)
  • Unit tests have a default max debug print limit, meaning that when a test fails it might not print the entire rendered HTML (which is helpful for debugging). If you need to see the entirety of the rendered HTML, you can run the test command like so: DEBUG_PRINT_LIMIT=50000 npm run test

E2E tests

We use Playwright to test our code end-to-end.

We write E2E tests for important user flows and logic that can’t be tested with unit/integration tests.

E2E tests sit under the tests/e2e directory; different test files (.spec.ts) should be created according to the feature they check / their purpose. We follow the POM (Page Object Model) pattern for writing E2E tests, which means that each page has its own page object, and each page object has its own methods for interacting with the page. This pattern helps us keep our tests clean, readable and maintainable.

To read further about the conventions we follow for writing E2E tests, see the adjacent document on FE conventions.

Setup instructions:

By default, when running the e2e tests with the above commands, they are configured to run against a dev environment running on http://localhost:3000. If you want to run the tests against a different environment (whether it’s the Tilt front service, a remote ArgoCD dev environment or the staging/production apps), follow these guidelines:

  • when running the command to start playwright, make sure you pass the correct VEGA_ENV variable according to which environment you want to test against.

  • when switching between testing environments, you should also ensure the secrets are aligned with the environment you’re testing against. For example, if you’re testing against the staging environment, you ensure that the E2E_ACCESS_KEY is set to the correct access key for the staging environment.