Front-End-Checklist 测试质量进阶用 Stryker 突变测试衡量测试套件的真实缺陷检出能力【免费下载链接】Front-End-Checklist The essential checklist for modern web development, for humans and AI agents项目地址: https://gitcode.com/gh_mirrors/fr/Front-End-Checklist导读行覆盖率 90% 的测试套件依然可能把严重 bug 放进生产环境——只要测试只是执行了代码而没有断言有意义的输出。突变测试Mutation Testing通过向源码注入微小而合理的 bug突变体验证你的测试能否区分正确代码与细微损坏的代码这正是生产环境真正需要的质量标准。本文以 skills/mutation-testing/SKILL.md 及其完整实现参考 skills/mutation-testing/references/rule.md 为主体系统讲解 Stryker 突变测试的原理、配置、报告解读、关键路径聚焦、CI 集成与测试改进实战并对照本仓库Front-End-Checklist的测试基础设施与规则内容给出可落地的验证方法。读完你将掌握如何用突变分数取代覆盖率数字游戏如何配置 Stryker 让构建在测试质量不达标时失败以及如何用少量精准测试杀死幸存突变体。为什么行覆盖率不是质量的真相一个仓库可以有 90% 的行覆盖率仍然发布携带严重 bug 的版本。原因在于覆盖率只回答一个问题哪些行被执行了它不回答测试是否断言了正确的结果。这正是 packages/content/rules/en/testing/mutation-testing.mdx 中whyItMatters强调的核心观点A codebase can have 90% line coverage and still ship critical bugs if tests only execute code without asserting meaningful outcomes.在本仓库的测试基线 jest.base.cjs 中可以看到典型的覆盖率门槛配置branches 70、functions 80、lines 80、statements 80各包如 apps/web/jest.config.cjs通过createPackageJestConfig继承该门槛。这类配置保证了执行到的代码比例但正如 test-coverage.mdx 中Best Practices一节所示覆盖率再高也无法识别只调用不断言的空测试。突变测试补上的正是这块缺口它验证的是如果代码坏了测试是否会红。突变测试的核心概念与突变分数公式突变测试的工作方式自动向源代码注入小而合理的 bug——称为突变体mutants——然后针对每个突变体运行你的测试套件如果测试失败该突变体被杀死killed说明测试抓住了这个 bug如果突变体存在而所有测试仍通过该突变体幸存survived说明测试漏掉了这一类 bug。**突变分数mutation score**即被杀死突变体的百分比mutation score (killed mutants / total mutants) × 100分数 80% 意味着注入的 80% 的 bug 被测试捕获。本仓库将这条规则收录在 packages/content/rules/en/testing/mutation-testing.mdx 中元数据将其定级为priority: medium、difficulty: advanced、estimatedTime: 120分钟并归属于testing / best-practices分类。SKILL 文件skills/mutation-testing/SKILL.md也明确给出四条速览结论代码覆盖率告诉你哪些行被执行突变分数告诉你哪些 bug 被捕获Stryker 注入小型代码变更突变并检查测试是否失败——不失败说明测试薄弱关键业务逻辑路径的目标是 80% 的突变分数在聚焦范围单个模块上运行 Stryker而非整个代码库以控制 CI 时长。安装 Stryker 与相关插件Stryker 是 JavaScript/TypeScript 生态最主流的突变测试框架。按照 skills/mutation-testing/references/rule.md 的Code Examples先安装核心包、测试运行器插件与类型检查器pnpm add -D stryker-mutator/core stryker-mutator/vitest-runner stryker-mutator/typescript-checker三个包的分工stryker-mutator/coreStryker 主框架负责生成突变体、调度测试运行、汇总分数stryker-mutator/vitest-runner测试运行器插件将 Stryker 与 Vitest 桥接。仓库中多数包如 packages/data-layer/jest.config.js、apps/web/jest.config.cjs使用的是 Jest因此实际项目中可按栈选择stryker-mutator/jest-runner、stryker-mutator/vitest-runner或stryker-mutator/mocha-runnerstryker-mutator/typescript-checker类型检查器先用 TypeScript 类型系统过滤掉注定编译失败的突变体避免把类型错误突变白白跑一遍测试套件。编写 stryker.config.mjs参数逐项解析以下配置来自 rule.md 的完整示例在 skills/mutation-testing/references/rule.md 中与 mutation-testing.mdx 中的版本一致后者还补全了export default与 JSDoc 类型注解// stryker.config.mjs /** type {import(stryker-mutator/core).PartialStrykerOptions} */ export default { // Test runner — use vitest, jest, or mocha depending on your stack testRunner: vitest, // TypeScript checker validates mutants against the type system first, // which avoids running type-error mutants through the test suite checkers: [typescript], tsconfigFile: tsconfig.json, // Focus mutation on critical business logic — not on test files, // config, or generated code mutate: [ src/lib/**/*.ts, src/utils/**/*.ts, !src/**/*.test.ts, !src/**/*.spec.ts, !src/**/*.d.ts, ], // Vitest config — point to your vitest config vitest: { configFile: vitest.config.ts, }, // Thresholds — the build fails if the mutation score drops below these values thresholds: { high: 80, // Green: good coverage low: 60, // Yellow: acceptable but should improve break: 50, // Red: fail the build }, // Run at most 4 tests in parallel per mutant to keep CI time reasonable concurrency: 4, // Report formats — html for local inspection, json for CI dashboards reporters: [html, clear-text, json], // Incremental mode caches results so only changed files are re-mutated in CI incremental: true, };关键参数的作用与取值建议参数作用取值范围 / 说明testRunner指定运行测试的框架vitest/jest/mocha等需配套安装对应-runner插件checkers在测试运行前用类型系统过滤突变体[typescript]需要tsconfigFiletsconfigFileTypeScript 检查器使用的配置文件指向项目根 tsconfig如tsconfig.jsonmutate声明哪些文件参与突变支持!排除只包含关键业务逻辑排除*.test.ts、*.spec.ts、*.d.tsthresholds分数门槛决定构建绿/黄/红high: 80、low: 60、break: 50低于 break 直接失败concurrency每个突变体并行执行的测试数上限调低可控制 CI 资源占用示例为 4reporters报告输出格式html本地查看、clear-text终端、jsonCI 面板incremental增量模式缓存结果只重跑变更文件CI 中显著缩短耗时建议true其中thresholds.break是 CI 守门的关键当突变分数低于该值时pnpm stryker run以非零退出码结束从而让构建失败。Stryker 生成的突变类型Stryker 会注入多种真实生产中会犯的错误风格的突变rule.md 中的完整清单突变类型示例算术运算符Arithmetic operatora b→a - b比较运算符Comparison operatorx 0→x 0逻辑连接符Logical connectora b→a \|\| b布尔字面量Boolean literalreturn true→return false字符串字面量String literalerror→数组声明Array declaration[1, 2, 3]→[]条件边界Conditional boundaryx limit→x limit块语句删除Block statement removal删除if分支体这些正是导致真实生产 bug 的那类微妙变更——差一错误off-by-one、错误的布尔逻辑、被漏掉的边界分支。你的测试若不能杀死它们就说明面对同类真实回归时同样会失守。读懂 HTML 报告绿、红、灰三色语义运行pnpm stryker run后打开reports/mutation/index.html。报告中每个文件以三种颜色标注绿色行该处全部突变体被杀——测试在此处有效红色行存在幸存突变体——测试缺少相应断言灰色行未生成突变体注释、类型声明等无法突变的内容。点击任意幸存突变体可以看到未被捕获的具体代码变更Survived: BooleanSubstitution on line 42 Original: return isValid isAuthorized Mutant: return false这条信息直接告诉你没有任何测试断言该函数在合法且已授权条件下返回true。这正是从覆盖率数字定位到缺失断言的最短路径。聚焦关键路径让突变测试在 CI 中跑得动在整个大型代码库上跑 Stryker 很慢。rule.md 建议从最重要的模块开始并给出了面向 CI 的聚焦配置完整版本见 mutation-testing.mdx// stryker.config.ci.mjs — focused config for CI export default { ...baseConfig, mutate: [ // Pricing calculations src/lib/pricing/**/*.ts, // Authentication logic src/lib/auth/**/*.ts, // Data validation utilities src/utils/validation/**/*.ts, !**/*.test.ts, ], thresholds: { high: 85, low: 70, break: 65 }, };要点通过mutate白名单把突变范围收缩到定价计算、认证逻辑、数据校验这类坏一点就出大事的模块同时把门槛上调high: 85 / low: 70 / break: 65——对关键路径要求更严格是合理的。这条策略与本仓库 unit-tests.mdx 中测试优先级表的判断一致付款计算金融准确性、表单校验数据完整性、认证逻辑安全性都属于最高优先级测试对象恰好也是突变测试最值得投入的靶区。实战改进用精准测试杀死幸存突变体rule.md 给出一个完整的定价计算案例。被测试代码// lib/pricing.ts export function calculateDiscount(price: number, memberLevel: basic | premium): number { if (memberLevel premium) { return price * 0.8; // 20% discount } return price * 0.95; // 5% discount for basic }一个只测了 premium 路径的弱测试// ❌ Only kills some mutants — the basic path is untested it(applies 20% discount for premium, () { expect(calculateDiscount(100, premium)).toBe(80); });这个测试只能杀死部分突变体basic分支及其边界完全裸奔。强测试显式覆盖两条路径与边界值// ✅ Explicitly tests both paths and edge values it(applies 20% discount for premium members, () { expect(calculateDiscount(100, premium)).toBe(80); expect(calculateDiscount(0, premium)).toBe(0); }); it(applies 5% discount for basic members, () { expect(calculateDiscount(100, basic)).toBe(95); }); // This test kills the return false boolean substitution mutant it(returns a positive discount for any positive price, () { expect(calculateDiscount(200, premium)).toBeGreaterThan(0); expect(calculateDiscount(200, basic)).toBeGreaterThan(0); });注意第三个用例的设计巧思它不是为了覆盖某个行而是为了杀死calculateDiscount被布尔替换类突变改坏后例如返回恒为 0 或负值的突变体断言任意正价格都得到正折扣。这种针对幸存突变反推断言的写法正是突变测试驱动测试设计mutation-driven test design的精髓。不要盲目追求 100% 突变分数有些突变体是等价突变体equivalent mutants——它们产生的代码与原文逻辑等价、仅结构不同理论上无法被任何测试杀死。追逐 100% 分数通常会导致过度指定的脆弱测试维护成本高昂。对大多数团队而言关键路径 80% 是务实目标rule.md 与 mdx 中的Warning块均强调此点。把突变测试接入 CIrule.md 提供了完整的 GitHub Actions 工作流mutate触发路径与聚焦配置中的src/lib/**、src/utils/**一一对应实现只有关键路径变更才触发突变测试# .github/workflows/mutation.yml name: Mutation Testing on: pull_request: paths: - src/lib/** - src/utils/** jobs: mutation: runs-on: ubuntu-latest steps: - uses: actions/checkoutv4 - uses: pnpm/action-setupv3 - run: pnpm install --frozen-lockfile - run: pnpm stryker run --config stryker.config.ci.mjs - name: Upload mutation report uses: actions/upload-artifactv4 if: always() with: name: mutation-report path: reports/mutation/设计要点路径过滤on.pull_request.paths限定只在src/lib/**、src/utils/**变更时触发避免每次 PR 都全量跑突变独立配置文件CI 使用stryker.config.ci.mjs聚焦配置 更高门槛与本地全量配置分离阈值即守门thresholds.break低于门槛时任务失败让测试质量退化直接阻塞合并而不是停留在告警报告可追溯actions/upload-artifactv4配合if: always()即使分数不达标也上传reports/mutation/供人工审查。这条自动验证 失败即阻塞的准则与本仓库 test-coverage.mdx 中Verification的要求一致确保自动化阻塞回归而不是只打印警告。作为 Agent 技能的使用流程skills/mutation-testing/SKILL.md 将该主题封装为可供 AI Agent 直接执行的技能front matter 中给出使用时机aiContext当评估包含业务逻辑、计算工具或状态机模块的测试质量判断测试是否具备真实缺陷检测能力时使用。其元数据为category: testing、priority: medium、difficulty: advanced、estimatedTime: 120。技能主体定义了一套标准的四阶段工作流Check检查评估该模块是否已配置突变测试关键路径的突变分数是否达到项目质量门槛Fix修复为该模块配置 Stryker运行初始突变报告改进测试以杀死关键业务逻辑路径中的幸存突变体Explain解释解释什么是突变测试、Stryker 如何工作以及为什么突变分数比单独的行覆盖率是更有意义的质量信号Code Review代码审查审查 Stryker 配置与突变报告定位关键代码路径中的幸存突变体并提出能够杀死它们的测试改进建议。完成阶段后按 rule.md 的Verification清单做最终验证运行pnpm stryker run确认突变分数达到配置的门槛打开 HTML 报告检查三个最关键源文件中的幸存突变体补充测试至少杀死边界条件类与布尔反转类幸存突变体重跑 Stryker确认分数提升。与本仓库其他测试规则的关系在 mutation-testing.mdx 的 front matter 中该规则声明了四组关联规则构成完整的测试质量体系关联规则关联理由unit-tests.mdx突变测试衡量单元测试的质量两者配合确保全面有效的测试覆盖test-coverage.mdx突变分数与覆盖率指标互补——同时使用两者才能看清测试套件质量的完整图景integration-testing.mdx两者共同影响测试质量通常一起审查mobile-testing.mdx两者共同影响测试质量通常一起审查实践中的合理组合是用覆盖率门槛如 jest.base.cjs 的 branches 70 / lines 80守住测到了什么用突变分数关键路径 80%守住测出了什么再以单元测试与集成测试的分层参考 TESTING-STRATEGY.md落实具体用例。覆盖率保证广度下限突变分数暴露断言盲区——两者结合才是测试真的能挡住 bug的完整证明。【免费下载链接】Front-End-Checklist The essential checklist for modern web development, for humans and AI agents项目地址: https://gitcode.com/gh_mirrors/fr/Front-End-Checklist创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Front-End-Checklist 测试质量进阶：用 Stryker 突变测试衡量测试套件的真实缺陷检出能力
Front-End-Checklist 测试质量进阶用 Stryker 突变测试衡量测试套件的真实缺陷检出能力【免费下载链接】Front-End-Checklist The essential checklist for modern web development, for humans and AI agents项目地址: https://gitcode.com/gh_mirrors/fr/Front-End-Checklist导读行覆盖率 90% 的测试套件依然可能把严重 bug 放进生产环境——只要测试只是执行了代码而没有断言有意义的输出。突变测试Mutation Testing通过向源码注入微小而合理的 bug突变体验证你的测试能否区分正确代码与细微损坏的代码这正是生产环境真正需要的质量标准。本文以 skills/mutation-testing/SKILL.md 及其完整实现参考 skills/mutation-testing/references/rule.md 为主体系统讲解 Stryker 突变测试的原理、配置、报告解读、关键路径聚焦、CI 集成与测试改进实战并对照本仓库Front-End-Checklist的测试基础设施与规则内容给出可落地的验证方法。读完你将掌握如何用突变分数取代覆盖率数字游戏如何配置 Stryker 让构建在测试质量不达标时失败以及如何用少量精准测试杀死幸存突变体。为什么行覆盖率不是质量的真相一个仓库可以有 90% 的行覆盖率仍然发布携带严重 bug 的版本。原因在于覆盖率只回答一个问题哪些行被执行了它不回答测试是否断言了正确的结果。这正是 packages/content/rules/en/testing/mutation-testing.mdx 中whyItMatters强调的核心观点A codebase can have 90% line coverage and still ship critical bugs if tests only execute code without asserting meaningful outcomes.在本仓库的测试基线 jest.base.cjs 中可以看到典型的覆盖率门槛配置branches 70、functions 80、lines 80、statements 80各包如 apps/web/jest.config.cjs通过createPackageJestConfig继承该门槛。这类配置保证了执行到的代码比例但正如 test-coverage.mdx 中Best Practices一节所示覆盖率再高也无法识别只调用不断言的空测试。突变测试补上的正是这块缺口它验证的是如果代码坏了测试是否会红。突变测试的核心概念与突变分数公式突变测试的工作方式自动向源代码注入小而合理的 bug——称为突变体mutants——然后针对每个突变体运行你的测试套件如果测试失败该突变体被杀死killed说明测试抓住了这个 bug如果突变体存在而所有测试仍通过该突变体幸存survived说明测试漏掉了这一类 bug。**突变分数mutation score**即被杀死突变体的百分比mutation score (killed mutants / total mutants) × 100分数 80% 意味着注入的 80% 的 bug 被测试捕获。本仓库将这条规则收录在 packages/content/rules/en/testing/mutation-testing.mdx 中元数据将其定级为priority: medium、difficulty: advanced、estimatedTime: 120分钟并归属于testing / best-practices分类。SKILL 文件skills/mutation-testing/SKILL.md也明确给出四条速览结论代码覆盖率告诉你哪些行被执行突变分数告诉你哪些 bug 被捕获Stryker 注入小型代码变更突变并检查测试是否失败——不失败说明测试薄弱关键业务逻辑路径的目标是 80% 的突变分数在聚焦范围单个模块上运行 Stryker而非整个代码库以控制 CI 时长。安装 Stryker 与相关插件Stryker 是 JavaScript/TypeScript 生态最主流的突变测试框架。按照 skills/mutation-testing/references/rule.md 的Code Examples先安装核心包、测试运行器插件与类型检查器pnpm add -D stryker-mutator/core stryker-mutator/vitest-runner stryker-mutator/typescript-checker三个包的分工stryker-mutator/coreStryker 主框架负责生成突变体、调度测试运行、汇总分数stryker-mutator/vitest-runner测试运行器插件将 Stryker 与 Vitest 桥接。仓库中多数包如 packages/data-layer/jest.config.js、apps/web/jest.config.cjs使用的是 Jest因此实际项目中可按栈选择stryker-mutator/jest-runner、stryker-mutator/vitest-runner或stryker-mutator/mocha-runnerstryker-mutator/typescript-checker类型检查器先用 TypeScript 类型系统过滤掉注定编译失败的突变体避免把类型错误突变白白跑一遍测试套件。编写 stryker.config.mjs参数逐项解析以下配置来自 rule.md 的完整示例在 skills/mutation-testing/references/rule.md 中与 mutation-testing.mdx 中的版本一致后者还补全了export default与 JSDoc 类型注解// stryker.config.mjs /** type {import(stryker-mutator/core).PartialStrykerOptions} */ export default { // Test runner — use vitest, jest, or mocha depending on your stack testRunner: vitest, // TypeScript checker validates mutants against the type system first, // which avoids running type-error mutants through the test suite checkers: [typescript], tsconfigFile: tsconfig.json, // Focus mutation on critical business logic — not on test files, // config, or generated code mutate: [ src/lib/**/*.ts, src/utils/**/*.ts, !src/**/*.test.ts, !src/**/*.spec.ts, !src/**/*.d.ts, ], // Vitest config — point to your vitest config vitest: { configFile: vitest.config.ts, }, // Thresholds — the build fails if the mutation score drops below these values thresholds: { high: 80, // Green: good coverage low: 60, // Yellow: acceptable but should improve break: 50, // Red: fail the build }, // Run at most 4 tests in parallel per mutant to keep CI time reasonable concurrency: 4, // Report formats — html for local inspection, json for CI dashboards reporters: [html, clear-text, json], // Incremental mode caches results so only changed files are re-mutated in CI incremental: true, };关键参数的作用与取值建议参数作用取值范围 / 说明testRunner指定运行测试的框架vitest/jest/mocha等需配套安装对应-runner插件checkers在测试运行前用类型系统过滤突变体[typescript]需要tsconfigFiletsconfigFileTypeScript 检查器使用的配置文件指向项目根 tsconfig如tsconfig.jsonmutate声明哪些文件参与突变支持!排除只包含关键业务逻辑排除*.test.ts、*.spec.ts、*.d.tsthresholds分数门槛决定构建绿/黄/红high: 80、low: 60、break: 50低于 break 直接失败concurrency每个突变体并行执行的测试数上限调低可控制 CI 资源占用示例为 4reporters报告输出格式html本地查看、clear-text终端、jsonCI 面板incremental增量模式缓存结果只重跑变更文件CI 中显著缩短耗时建议true其中thresholds.break是 CI 守门的关键当突变分数低于该值时pnpm stryker run以非零退出码结束从而让构建失败。Stryker 生成的突变类型Stryker 会注入多种真实生产中会犯的错误风格的突变rule.md 中的完整清单突变类型示例算术运算符Arithmetic operatora b→a - b比较运算符Comparison operatorx 0→x 0逻辑连接符Logical connectora b→a \|\| b布尔字面量Boolean literalreturn true→return false字符串字面量String literalerror→数组声明Array declaration[1, 2, 3]→[]条件边界Conditional boundaryx limit→x limit块语句删除Block statement removal删除if分支体这些正是导致真实生产 bug 的那类微妙变更——差一错误off-by-one、错误的布尔逻辑、被漏掉的边界分支。你的测试若不能杀死它们就说明面对同类真实回归时同样会失守。读懂 HTML 报告绿、红、灰三色语义运行pnpm stryker run后打开reports/mutation/index.html。报告中每个文件以三种颜色标注绿色行该处全部突变体被杀——测试在此处有效红色行存在幸存突变体——测试缺少相应断言灰色行未生成突变体注释、类型声明等无法突变的内容。点击任意幸存突变体可以看到未被捕获的具体代码变更Survived: BooleanSubstitution on line 42 Original: return isValid isAuthorized Mutant: return false这条信息直接告诉你没有任何测试断言该函数在合法且已授权条件下返回true。这正是从覆盖率数字定位到缺失断言的最短路径。聚焦关键路径让突变测试在 CI 中跑得动在整个大型代码库上跑 Stryker 很慢。rule.md 建议从最重要的模块开始并给出了面向 CI 的聚焦配置完整版本见 mutation-testing.mdx// stryker.config.ci.mjs — focused config for CI export default { ...baseConfig, mutate: [ // Pricing calculations src/lib/pricing/**/*.ts, // Authentication logic src/lib/auth/**/*.ts, // Data validation utilities src/utils/validation/**/*.ts, !**/*.test.ts, ], thresholds: { high: 85, low: 70, break: 65 }, };要点通过mutate白名单把突变范围收缩到定价计算、认证逻辑、数据校验这类坏一点就出大事的模块同时把门槛上调high: 85 / low: 70 / break: 65——对关键路径要求更严格是合理的。这条策略与本仓库 unit-tests.mdx 中测试优先级表的判断一致付款计算金融准确性、表单校验数据完整性、认证逻辑安全性都属于最高优先级测试对象恰好也是突变测试最值得投入的靶区。实战改进用精准测试杀死幸存突变体rule.md 给出一个完整的定价计算案例。被测试代码// lib/pricing.ts export function calculateDiscount(price: number, memberLevel: basic | premium): number { if (memberLevel premium) { return price * 0.8; // 20% discount } return price * 0.95; // 5% discount for basic }一个只测了 premium 路径的弱测试// ❌ Only kills some mutants — the basic path is untested it(applies 20% discount for premium, () { expect(calculateDiscount(100, premium)).toBe(80); });这个测试只能杀死部分突变体basic分支及其边界完全裸奔。强测试显式覆盖两条路径与边界值// ✅ Explicitly tests both paths and edge values it(applies 20% discount for premium members, () { expect(calculateDiscount(100, premium)).toBe(80); expect(calculateDiscount(0, premium)).toBe(0); }); it(applies 5% discount for basic members, () { expect(calculateDiscount(100, basic)).toBe(95); }); // This test kills the return false boolean substitution mutant it(returns a positive discount for any positive price, () { expect(calculateDiscount(200, premium)).toBeGreaterThan(0); expect(calculateDiscount(200, basic)).toBeGreaterThan(0); });注意第三个用例的设计巧思它不是为了覆盖某个行而是为了杀死calculateDiscount被布尔替换类突变改坏后例如返回恒为 0 或负值的突变体断言任意正价格都得到正折扣。这种针对幸存突变反推断言的写法正是突变测试驱动测试设计mutation-driven test design的精髓。不要盲目追求 100% 突变分数有些突变体是等价突变体equivalent mutants——它们产生的代码与原文逻辑等价、仅结构不同理论上无法被任何测试杀死。追逐 100% 分数通常会导致过度指定的脆弱测试维护成本高昂。对大多数团队而言关键路径 80% 是务实目标rule.md 与 mdx 中的Warning块均强调此点。把突变测试接入 CIrule.md 提供了完整的 GitHub Actions 工作流mutate触发路径与聚焦配置中的src/lib/**、src/utils/**一一对应实现只有关键路径变更才触发突变测试# .github/workflows/mutation.yml name: Mutation Testing on: pull_request: paths: - src/lib/** - src/utils/** jobs: mutation: runs-on: ubuntu-latest steps: - uses: actions/checkoutv4 - uses: pnpm/action-setupv3 - run: pnpm install --frozen-lockfile - run: pnpm stryker run --config stryker.config.ci.mjs - name: Upload mutation report uses: actions/upload-artifactv4 if: always() with: name: mutation-report path: reports/mutation/设计要点路径过滤on.pull_request.paths限定只在src/lib/**、src/utils/**变更时触发避免每次 PR 都全量跑突变独立配置文件CI 使用stryker.config.ci.mjs聚焦配置 更高门槛与本地全量配置分离阈值即守门thresholds.break低于门槛时任务失败让测试质量退化直接阻塞合并而不是停留在告警报告可追溯actions/upload-artifactv4配合if: always()即使分数不达标也上传reports/mutation/供人工审查。这条自动验证 失败即阻塞的准则与本仓库 test-coverage.mdx 中Verification的要求一致确保自动化阻塞回归而不是只打印警告。作为 Agent 技能的使用流程skills/mutation-testing/SKILL.md 将该主题封装为可供 AI Agent 直接执行的技能front matter 中给出使用时机aiContext当评估包含业务逻辑、计算工具或状态机模块的测试质量判断测试是否具备真实缺陷检测能力时使用。其元数据为category: testing、priority: medium、difficulty: advanced、estimatedTime: 120。技能主体定义了一套标准的四阶段工作流Check检查评估该模块是否已配置突变测试关键路径的突变分数是否达到项目质量门槛Fix修复为该模块配置 Stryker运行初始突变报告改进测试以杀死关键业务逻辑路径中的幸存突变体Explain解释解释什么是突变测试、Stryker 如何工作以及为什么突变分数比单独的行覆盖率是更有意义的质量信号Code Review代码审查审查 Stryker 配置与突变报告定位关键代码路径中的幸存突变体并提出能够杀死它们的测试改进建议。完成阶段后按 rule.md 的Verification清单做最终验证运行pnpm stryker run确认突变分数达到配置的门槛打开 HTML 报告检查三个最关键源文件中的幸存突变体补充测试至少杀死边界条件类与布尔反转类幸存突变体重跑 Stryker确认分数提升。与本仓库其他测试规则的关系在 mutation-testing.mdx 的 front matter 中该规则声明了四组关联规则构成完整的测试质量体系关联规则关联理由unit-tests.mdx突变测试衡量单元测试的质量两者配合确保全面有效的测试覆盖test-coverage.mdx突变分数与覆盖率指标互补——同时使用两者才能看清测试套件质量的完整图景integration-testing.mdx两者共同影响测试质量通常一起审查mobile-testing.mdx两者共同影响测试质量通常一起审查实践中的合理组合是用覆盖率门槛如 jest.base.cjs 的 branches 70 / lines 80守住测到了什么用突变分数关键路径 80%守住测出了什么再以单元测试与集成测试的分层参考 TESTING-STRATEGY.md落实具体用例。覆盖率保证广度下限突变分数暴露断言盲区——两者结合才是测试真的能挡住 bug的完整证明。【免费下载链接】Front-End-Checklist The essential checklist for modern web development, for humans and AI agents项目地址: https://gitcode.com/gh_mirrors/fr/Front-End-Checklist创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考