Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Define the frontend mutation-testing merge policy from measured evidence

Open
  • Is something wrong?
#8,814 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
35/100
Issue type
Documentation
Clarity
Clearly specified
Activity status
Active
Tech stack
javascript
Domain
frontend, testing-qa

Research direction

Begin after prerequisites #8812 and #8813, then read the baseline mutation report and review full-run time, surviving-mutant categories, CI reliability, frontend change frequency, and Stryker incremental-mode results with Vitest. Done means documenting the measured quality gate, handling of surviving and equivalent mutants, tool failures versus score regressions, the incremental PR decision, and the focused follow-up policy.

Written by the indexing model from the issue text.

Description

frontend javascript

Goal

Define how frontend mutation testing should protect LibreSign pull requests after the complete baseline, incremental benchmark and observational pull-request workflow have produced real project data.

Use measured LibreSign evidence together with current StrykerJS guidance and mutation-testing literature.

Do not choose a score threshold only because another project uses it.

Inputs

Review:

  • complete frontend baseline results;
  • incremental benchmark results;
  • real observational PR workflow runs;
  • full-run execution time;
  • normal PR mutation-test latency;
  • recurring surviving-mutant categories;
  • CI reliability;
  • incremental-state invalidation behavior;
  • normal frontend change frequency.

Decisions

Document explicit answers for:

  1. whether mutation score, covered-code mutation score or another signal should be the blocking score;
  2. what threshold, if any, is justified for changed code;
  3. whether individual surviving mutants should block independently of a score threshold;
  4. how no-coverage changed code should be treated;
  5. how equivalent or non-actionable mutants should be documented;
  6. how test-only pull requests should be evaluated;
  7. which changes must invalidate incremental state or trigger the broader safety mode;
  8. what normal PR mutation-test latency is acceptable;
  9. how operational failures differ from mutation-score regressions.

Incremental safety

StrykerJS incremental mode can detect mutated source and test changes, and the Vitest runner reports exact test locations.

However, incremental mode does not automatically detect all environment and support-file changes.

The policy must explicitly define broader execution for changes that invalidate incremental assumptions, including relevant dependency, configuration, environment, snapshot or shared-test-infrastructure changes.

Fixed safety requirements

The policy must preserve these requirements unless later evidence demonstrates a safer equivalent:

  • mutation testing runs before merge for mutation-relevant frontend pull requests;
  • operational Stryker/Vitest failures fail the mutation check;
  • the complete mutation suite is not required on every normal pull request when a validated incremental strategy provides reliable merge protection;
  • untrusted or incompatible incremental state is not silently reused.

Score changes

Do not lower an established threshold simply because a new change fails it.

Investigate the regression first.

If an established threshold later becomes technically unrepresentative, change it in a dedicated PR with evidence explaining why.

Follow-up policy

Mutation testing will continue to identify historical test weaknesses after this epic closes.

Create focused issues when a surviving mutant exposes a meaningful unprotected behavior.

Do not reopen or extend this infrastructure epic as a permanent mutant backlog.

Done when

  • LibreSign has a documented frontend mutation-testing merge policy.
  • Any blocking score is justified by measured project data.
  • Incremental-state invalidation and broad-mode triggers are explicit.
  • Test-only pull-request behavior is explicit.
  • Equivalent/non-actionable mutant handling is documented.
  • Operational failures and score regressions are treated separately.
  • Normal PR latency expectations are documented.
  • The policy provides enough information to configure a required merge check.

References

Dominant language
PHP
Stars
818
Forks
146
Avg merge
7h 8m
Merged PRs (30d)
549

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from LibreSign/libresign

All issues in LibreSign/libresign

Similar issues

More PHP issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.