Skip to content

ADR-017 - Testing Strategy

Statusaccepted
Date2025-04-14
Decision MakersDardan Bujupaj (AX), Marc Gähwiler (AX)

Context

As decided in ADR-009 - Deployment Process changes will first be tested on an Integration Test environment before being deployed to the User Acceptance Test environment. This will catch issues early in the development process, ensuring that any potential regressions are identified and fixed before being tested by Griesser, therefore increasing efficiency. To achieve this, we need to establish a robust testing strategy that covers all critical aspects of the application.

Decision

We will setup multiple testing stages covering different aspects of the application.

Unit tests

To make sure changes don’t break existing functionality unit tests will be written where it makes sense (For example when adding a new feature or fixing a bug). We don’t strive for full test coverage, but rather focus on testing the most critical parts of the application. This means that unit tests will not be required, developers or reviewers will decide if unit tests are necessary.

Unit tests will only run on pull requests with changes to the according module (frontend/backend). They will run automatically on every commit to the repository. Deployment to the Integration Test environment will only happen if all unit tests pass.

Integration Tests

To make sure APIs work as expected we will test the API endpoints of the application on every deployment to the Integration Test environment.

End to End Tests

To make sure the system works well with related systems a suite of end to end tests will be written. The tests will run for every deployment on the Integration Test environment. Each test will reflect a series action a user is expected to perform. These will be commonly used workflows as well as critical edge cases.

Consequences

  • Pipelines need to be created to run unit tests for frontend or backend on each pull request
  • Pipelines need to be created to run end to end tests as well as API tests on each deployment to the Integration Test environment
    • Upon successful completion of all tests, deployment to the User Acceptance Tests should be triggered

Alternatives

  • don’t run tests: Not running tests will increase the rejected changes from the User Acceptance Test environment, thus lead to increased communication overhead and development time.
  • other testing frameworks: vitest, pytest and playwright all have large adoption and are well maintained.