Description: package.json already defines "test:mutation": "stryker run" and the @stryker-mutator/core/@stryker-mutator/jest-runner devDependencies are installed, but .github/workflows/ci.yml's backend job never invokes it — mutation testing exists in the toolchain but isn't run anywhere. Add a scheduled CI job that runs npm run test:mutation and tracks the mutation score over time.
Problem Statement & Context: Line/branch coverage (already gathered via npm test -- --coverage in the backend job) doesn't measure whether tests actually catch behavioral regressions — mutation testing does, and it's already fully configured in this repo's tooling but sitting completely unused, representing wasted setup investment and a real gap in test-quality signal.
Scope & Acceptance Criteria:
- Add a scheduled (not per-PR, given typical mutation-testing runtime) CI job invoking
npm run test:mutation.
- Persist/report the resulting mutation score across runs (e.g. commit a score-history file, or post to a PR comment/dashboard) so regressions in test quality are visible over time, not just in a single run's raw output.
- Out of scope: fixing any surviving mutants the run uncovers — file those as follow-up issues; this issue delivers the CI job and trend tracking.
Implementation Guidelines:
- Key files:
package.json (test:mutation script), Stryker config (locate/verify the config file — likely stryker.conf.json/.js/.mjs at repo root; confirm actual filename before writing the CI step), .github/workflows/ci.yml.
- Run on a schedule (e.g. weekly) as a separate workflow file rather than folding into
ci.yml's per-PR backend job, given mutation testing's higher runtime cost.
- Decide the trend-storage mechanism (committed history file vs. external dashboard) based on what's realistic to maintain without extra infrastructure.
- Testing: run the job manually (workflow_dispatch trigger) at least once and include the actual mutation score and a sample of surviving mutants in the PR as evidence it works end-to-end.
Definition of Done:
- Scheduled mutation-testing job added, trend tracking implemented, verified working.
- Acceptance criteria met.
- PR passes CI, includes a real mutation-testing run's output.
- Reviewed and approved.
Resources: package.json, Stryker config file, .github/workflows/ci.yml
Complexity: High (200 points)
Description:
package.jsonalready defines"test:mutation": "stryker run"and the@stryker-mutator/core/@stryker-mutator/jest-runnerdevDependencies are installed, but.github/workflows/ci.yml'sbackendjob never invokes it — mutation testing exists in the toolchain but isn't run anywhere. Add a scheduled CI job that runsnpm run test:mutationand tracks the mutation score over time.Problem Statement & Context: Line/branch coverage (already gathered via
npm test -- --coveragein thebackendjob) doesn't measure whether tests actually catch behavioral regressions — mutation testing does, and it's already fully configured in this repo's tooling but sitting completely unused, representing wasted setup investment and a real gap in test-quality signal.Scope & Acceptance Criteria:
npm run test:mutation.Implementation Guidelines:
package.json(test:mutationscript), Stryker config (locate/verify the config file — likelystryker.conf.json/.js/.mjsat repo root; confirm actual filename before writing the CI step),.github/workflows/ci.yml.ci.yml's per-PRbackendjob, given mutation testing's higher runtime cost.Definition of Done:
Resources:
package.json, Stryker config file,.github/workflows/ci.ymlComplexity: High (200 points)