Skip to content

Repository navigation

12. Testing Plan & Continuous Integration

Jump to bottom
Kristi Doce edited this page Oct 7, 2026 · 1 revision

Testing Strategy

  • Every developer is responsible for writing unit tests for the features they implement.
  • Existing tests must be updated when related functionality is modified or any changes have been made.
  • Developers should run and verify their tests locally before opening a Pull Request.
  • Automated tests will also run through the CI pipeline.
  • Codecov will be used to monitor and report test coverage.
  • Sonar will be used for static code analysis to identify code quality, maintainability, and potential security issues.

Continuous Integration

The project uses GitHub Actions to automate the Continuous Integration (CI) process.

The CI pipeline is triggered when:

  • A Pull Request is opened or updated against main.
  • Changes are pushed to main.

The pipeline detects whether changes affect the frontend or backend and runs the corresponding CI workflow.

The CI process will include:

  • Running automated tests.
  • Reporting test coverage through Codecov.
  • Performing code quality and static analysis using Sonar.
  • Verifying that the relevant CI checks pass before integration.

After changes are merged into main, the pipeline also supports automatic version tagging and draft release preparation. Releases are published manually through GitHub Actions.

Pull Request & Code Review Rules

  • Every PR requires at least two reviewers.
  • The reviewer must provide meaningful/relevant feedback.
  • "Looks good to me" alone is not considered a sufficient review.
  • If issues are found, the reviewer must use Request changes and explain what needs to be fixed.
  • The author must address requested changes before merging.
  • PRs should be tested before requesting review.
  • All team members should follow the PR template.

Clone this wiki locally