测试覆盖率的陷阱：介绍使用 Stryker 和 Cosmic Ray 的变异测试

Source: Dev.to

（未提供需要翻译的正文内容。如需翻译文章，请粘贴完整文本。）

概述

目标：克服代码覆盖率指标的局限性，引入 mutation testing（变异测试），以验证测试代码确实捕获业务逻辑中的错误。

范围：企业编排器项目（Ochestrator）的核心模块，涵盖前端（TypeScript）和后端（Python）。

预期结果：通过获得超越单纯行覆盖的 mutation score（变异分数），提升代码稳定性和测试可靠性。

我们常常认为高测试覆盖率意味着代码安全。然而，要回答以下问题却很困难：

“谁在测试测试？”

仅仅执行代码而没有适当断言的测试仍然会计入覆盖率指标。为了解决这个 coverage trap，我们引入了变异测试。

实现

1. TypeScript 环境 – Stryker Mutator

对于 TypeScript 环境（前端和通用工具），我们选择了 Stryker。它与 Vitest 集成良好，且配置简便。

技术栈：TypeScript、Vitest、Stryker Mutator

关键配置（stryker.config.json）

{
  "testRunner": "vitest",
  "reporters": ["html", "clear-text", "progress"],
  "concurrency": 4,
  "incremental": true,
  "mutate": [
    "src/utils/**/*.ts",
    "src/services/**/*.ts"
  ]
}

我们启用了 incremental 选项，以仅在已更改的文件上运行测试。

2. Python 环境 – Cosmic Ray

对于后端，我们引入了 Cosmic Ray。它通过利用 Python 的动态特性来操作抽象语法树（AST），生成强大的变异。

技术栈：Python、Pytest、Cosmic Ray、Docker

执行架构：变异测试资源消耗大，因此我们在多个 Docker 工作节点上并行运行。

# Partial docker-compose.test.yaml
cosmic-worker-1:
  command: uv run cosmic-ray worker cosmic.sqlite

cosmic-runner:
  depends_on: [cosmic-worker-1, cosmic-worker-2]
  command: |
    uv run cosmic-ray init cosmic-ray.toml cosmic.sqlite
    uv run cosmic-ray exec cosmic-ray.toml cosmic.sqlite

调试 / 挑战

实际案例：VideoSplitter.ts 中存活的突变体

VideoSplitter.ts 负责视频分割。它的代码行覆盖率超过 95%，但 Stryker 仍然发现了许多存活的突变体。

问题陈述

// Original code
if (availableMemory  {
  // Simulate situations where memory is exactly equal to or slightly less than requiredMemory
  // ... reinforced test code ...
});

结果

• 已发现并移除 12 存活的变异体 于核心实用模块。
• 将测试代码从仅仅 执行 代码提升为真正 验证 代码。

关键指标

关键要点

• 覆盖率只是起点 – 行覆盖率告诉你 哪些未被测试，而不是 已测试内容的质量。
• 变异测试成本高但值得 – 运行可能需要数十分钟，但对核心业务逻辑的收益巨大。
• 渐进式采用 – 从关键基础设施代码（例如 VideoSplitter）开始，先建立成功案例，再进行扩展。

Verification Checklist

• 概述 – 目标和范围清晰。
• 实现 – 包含技术栈和代码示例。
• 调试 – 描述了至少一个具体问题及其解决方案。
• 结果 – 提供了数值数据和性能指标。
• 关键要点 – 概述了经验教训和未来计划。

长度指南

• 总体：400–800 行（当前约 100 行——如有需要可扩展）。