Establish the initial complete frontend mutation-testing baseline in CI
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 45/100
- Issue type
- Feature
- Clarity
- Mostly clear
- Activity status
- Active
- Tech stack
- javascript, typescript
Research direction
After prerequisite issue #8811, run Stryker against representative TypeScript, JavaScript, and Vue frontend areas such as helpers, Pinia stores, composables, validation, models, and behavior-rich components. Record mutation counts, runtime, resource use, and surviving-mutant classifications. Document the recommended scope and justified exclusions without adding a threshold, and move meaningful weaknesses into focused follow-up issues.
Written by the indexing model from the issue text.
Description
Goal
Run and document the initial complete LibreSign frontend mutation-testing baseline in GitHub Actions.
This issue measures the current frontend test suite.
It must not turn into an attempt to eliminate every surviving mutant.
Prerequisites
The basic Stryker/Vitest integration and complete CI mutation workflow must be available.
Execution
Run the complete configured StrykerJS mutation scope in GitHub Actions.
Do not use a maintainer workstation as the authoritative baseline.
Record the exact:
- LibreSign commit SHA;
- Node version;
- StrykerJS version;
- Vitest version;
- relevant Stryker configuration;
- worker/concurrency configuration when relevant.
What to record
At minimum:
- total mutants;
- killed mutants;
- surviving mutants;
- no-coverage mutants;
- timeout/error mutants;
- mutation score;
- covered-code mutation score when available;
- total runtime;
- approximate runner resource use when relevant.
Classify recurring surviving-mutant patterns.
Examples may include:
- real missing behavior assertions;
- equivalent or non-observable mutants;
- Vue declaration or metadata mutations with no observable behavioral effect;
- generated or declarative code;
- tests that execute code but do not validate the result;
- code that is difficult to test because responsibilities are coupled.
Do not assume a surviving mutant automatically requires a new test.
Scope review
Use the complete baseline to validate the project's normal mutation scope for:
- TypeScript;
- JavaScript;
- Vue SFCs where supported and useful;
- generated/non-behavioral paths that should remain excluded.
Every exclusion must have a technical reason independent of improving the score.
Thresholds
Do not introduce a blocking threshold in this issue.
The purpose of the baseline is to provide evidence for the later merge-policy decision.
Do not choose a target such as 80% or 100% without LibreSign data.
Follow-up issues
When the baseline identifies a meaningful testing weakness in a small cohesive area, create a separate focused issue.
Do not append a permanent mutant backlog to this baseline issue.
Done when
- A complete frontend mutation run finishes in GitHub Actions.
- Runtime and mutation counts are recorded.
- The exact environment and commit are recorded.
- Surviving mutants are sampled and classified.
- The configured mutation scope and exclusions have documented reasons.
- Reports needed for incremental benchmarking and later analysis are preserved.
- No arbitrary blocking threshold is introduced.
- Meaningful test weaknesses that deserve implementation work are tracked separately.
References
- Parent epic: #8810
- Complete CI workflow: #8813
- Dominant language
- PHP
- Stars
- 828
- Forks
- 157
- Avg merge
- 6h 48m
- Merged PRs (30d)
- 622
Getting set up
Starts the project's dev container in your browser, under your own GitHub account.
- No Dockerfile or Docker Compose file
- Has a pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from LibreSign/libresign
-
good first issue
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
LibreSign/libresign#8284 · 5 comments ·
Maintainers usually reply within 1 day
-
Difficulty 5/5 Over a week Newbie friendliness 15/100
Maintainers usually reply within 1 day
-
Difficulty 5/5 Over a week Newbie friendliness 15/100
Maintainers usually reply within 1 day
-
Difficulty 5/5 Over a week Newbie friendliness 20/100
Maintainers usually reply within 1 day
-
Difficulty 5/5 Over a week Newbie friendliness 25/100
Maintainers usually reply within 1 day
All issues in LibreSign/libresign
Similar issues
-
sync-en
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 2 days
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 2 days
-
UX
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
ProfessionalWiki/NeoWiki#1573 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100