自动化测试修复工具

测试genie mcp

专为vibe程序员设计：只需一个命令，即可获得项目实际损坏的优先级列表。

iOS、Android、Flutter、React Native和Web应用程序的自愈测试自动化——作为MCP服务器。

v3.1.1——氛围检查+诚实自动修复。 一次MCP调用，约30秒：竞争条件+安全问题+内存泄漏+逻辑错误+性能气味，按优先级排列。留在你的机器上，没有遥测。通过 autoFix: true 用于小型、安全的机械修复（弱哈希、简单 Math.random 赋值）--备份+语法验证+语法失败时回滚。对于经过测试验证的更难修复的应用程序，请使用 v3.0.0的迭代修复循环。

Vibe编码器快速入门

你不看文件。你打开项目，和克劳德谈谈，想要一个判决。这是：

在Claude中（安装了测试精灵mcp-- 设置):

/vibe-check /Users/me/my-app

克劳德打电话来 diagnose_project 引擎盖下。大约30秒后，您将看到：

# vibe-check report

- Project: /Users/me/my-app
- Platform: web
- Findings: 11 total — 4 critical, 4 high, 1 medium, 1 low
- Estimated fix time: ~85 min

## Top 5 issues

### 1. [CRIT] Hardcoded AWS access key id found in source
- File: `server.js:7`
- Category: security / secret (CWE-798)
- Confidence: 95%
- Fix: Move the value to an env var, gitignore the config, rotate the leaked key.

### 2. [CRIT] SQL string built by concatenating user input
- File: `server.js:21`
- Category: security / injection (CWE-89)
- Fix: Use parameterized queries (`db.query("... WHERE id = ?", [id])`).

### 3. [HIGH] useState setter called after await without mount guard
- File: `UserProfile.tsx:16`
- Category: race-condition / react-setstate-after-await (CWE-362)
- Confidence: 78%
- Fix: Use AbortController and check signal.aborted before calling setters.

… (top 5 shown — full list at output: "detailed")

## Next steps
1. Address the critical / high findings above.
2. Re-run diagnose_project after fixing to confirm convergence.
3. Use run_iterative_fix_loop for test-driven verification of each fix.

如果有任何发现 autoFixable: true 并且位于 high/critical 严重性 diagnose_project 呼叫接受 autoFix: true 要直接应用机械替换（使用备份+语法验证），请参阅 安全.md 对于确切的警卫）。v3.1.1的诚实范围很窄：弱哈希(createHash('md5'|'sha1') → createHash('sha256'))独立 Math.random() 在安全敏感文件中。对于更广泛的/结构性的修复（竞争条件、eval、exec注入），运行 run_iterative_fix_loop 单独地，它会重新运行测试并自动回滚回归。

为什么要测试精灵？

移动+跨平台测试自动化的瓶颈不是编写测试，而是循环 之间 失败的测试和通过的测试。testgenie关闭了这个循环：

failing test → analyzer flags issue → fix proposed → dry-run + syntax check →
applied with backup → affected tests re-run → regression check → loop or stop

这个完整的循环是 run_iterative_fix_loop 工具。这 diagnose_project autoFix: true v3.1.1中的路径涵盖了一个严格的子集——备份+试运行+语法验证+应用， 没有 重新运行测试（因此该路径中没有测试回归回滚）。使用适合工作的工具——并查看 安全.md 对于每个人的确切警卫。

其他工具（排毒、大师、剧作家、， xcodebuild test)运行测试。测试精灵 运行测试 和 驱动修复程序，直到达到标准或无法再取得进展 --不用你擦洗烟囱的痕迹。

5分钟快速入门

# 1. Install
npm install -g test-genie-mcp

# 2. Add to Claude Desktop config (~/.config/claude/claude_desktop_config.json)
{
  "mcpServers": {
    "test-genie": {
      "command": "npx",
      "args": ["test-genie-mcp"],
      "env": {
        "TEST_GENIE_ALLOWED_ROOT": "/path/to/your/project"
      }
    }
  }
}

# 3. Restart Claude Desktop. From a chat:
#    "Run the iterate-fix loop on /Users/me/my-rn-app with autoApply=false"

预期输出（截断）：

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Iterative fix loop f8b3… — PAUSED-FOR-CONFIRMATION
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Iterations completed: 1
Fixes applied:        0
Regressions rolled back: 0
Final tests:          7/10 passing (3 failing)

Pending confirmations (3):
  - 71fbe…: Fix: useEffect missing cleanup for setInterval (confidence: 85)
  - 92ad1…: Fix: Force-unwrap on possibly-undefined name (confidence: 85)
  - …

Resume token: f8b3…

重新呼叫 autoApply: true （或 resumeToken: "f8b3…")以实际修补文件。

实际使用案例

以下流程描述了 run_iterative_fix_loop 路径 （v3.0 标题）--完全检测→ 提议→ 干跑→ 应用备份→ 重新运行测试→ 回退。这 diagnose_project autoFix v3.1.1中的路径是更窄的机械替换专用路径；看见 安全.md §4指的是那个人实际接触到的东西。

1.React Native内存泄漏自愈

一个团队补充道 setInterval(...) 在一个 useEffect 忘记了清理。测试精灵 detect_memory_leaks 标记它， suggest_fixes 提出 return () => clearInterval(id) (src/tools/fixing/suggestFixes.ts:169-179)，循环通过TS编译器干运行补丁，应用备份，仅重新运行受影响的快照测试，确认100%通过，停止。 之前： 1个快照失败。 之后： 0个失败，1个修复程序已应用，1个备份位于 .test-genie-backups/.

2.Flutter小部件 dispose() 自动化

AnimationController 没有争议。测试精灵看到了丢失的东西 dispose() override，生成Dart @override dispose() { controller.dispose(); super.dispose(); } 挡块(suggestFixes.ts:214-217)，运行 dart analyze 在修补文件上，应用、重新运行 flutter test，收敛。

3.iOS保留周期（闭包捕获）

self.timer = Timer.scheduledTimer(...) { _ in self.tick() } --基于规则的检测器标记闭包自捕获，修复程序重写为 [weak self] _ in guard let self = self else { return }; self.tick() (suggestFixes.ts:239-242).如果 swiftc 在PATH上，语法检查是真实的；否则，testgenie会报告“降级验证”，所以你知道。

迭代修复循环的工作原理

┌────────────────────┐
│   collect tests    │  (run_scenario_test / supplied list)
└─────────┬──────────┘
          │
   pass-rate ≥ threshold? ── yes ──▶  SUCCESS
          │ no
          ▼
┌────────────────────┐
│  detect issues     │   memory + logic analyzers
└─────────┬──────────┘
          │
┌────────────────────┐
│  suggest fixes     │   rule-based (default) → LLM (hybrid, optional)
└─────────┬──────────┘
          │
┌────────────────────┐
│  dry-run + syntax  │   TS compiler API / platform compiler / brace check
└─────────┬──────────┘
          │
┌────────────────────┐
│  apply with backup │   per-file `.test-genie-backups/`
└─────────┬──────────┘
          │
┌────────────────────┐
│  re-run tests      │   regression?  yes → auto-rollback
└─────────┬──────────┘
          │
          ▼
   loop (≤ maxIterations, ≤ totalTimeout)

看 docs/ITERATE_FIX_LOOP.md 查看序列图和完整的安全防护列表。

工具（23）

mode 传奇在 docs/SIMULATION_VS_REAL.md.

加上4个资源(test-genie://iteration-logs, …/test-history/{path}, …/iteration-logs/{loopId}, …/applied-fixes/{path})3个提示(full-test-pipeline, diagnose-failure, vibe-check).

什么样的氛围检查捕捉到

比赛条件(detect_race_conditions / diagnose_project):

v3.1.1诚信审计： useEffect-no-abort 和 forEach-await 是 之前宣传为可自动修复。它们不是——用 AbortController 或重写为 Promise.all(arr.map(...)) 变化 我们无法静态验证的行为。他们现在只做报告。看 安全.md.

安全(detect_security_issues / diagnose_project):

v3.1.1诚信审计： .env/Math.random （一般）/yaml.load 是 之前宣传为可自动修复。他们要么太冒险了 盲目重写或不发布策略——翻转为只报告。看 安全.md §5.

氛围检查遗漏了什么（诚实清单）

这是一个“在30秒内捕捉明显的东西”过滤器，而不是Snyk/Semgrep/一个完整的SAST工具。我们没有抓住：

• 跨文件数据流。 如果用户输入在到达某个文件之前流过三个文件 db.query，正则表达式不会连接点。真正的SAST在调用图中跟踪污点。路线图：ts变形参考步行前N个入口点。
• 易受攻击的传递性deps。 我们不查询npm公告——这是 npm audit将一份过时的咨询清单捆绑在一起会撒谎。跑 npm audit --json 如果你想获得depCVE保险，请同时进行。
• 跨流程的竞赛条件。 我们捕获进程内的JS/Swift/Kotlin/Go竞争。分布式竞争（跨服务的锁排序、DB事务）需要不同的工具。
• 键入正确但逻辑错误的代码。 分析器是句法的，而不是语义的。A. Math.random() 命名 getNonce 不会骗我们的；一个名字恰当的 crypto.randomBytes 与微小的熵预算一起使用。
• 自定义秘密格式。 具有唯一前缀的内部公司令牌需要一个可以添加到的正则表达式 securityAnalyzer.SECRET_PATTERNS.PR欢迎。
• 实时/动态问题。 负载下内存泄漏、网络超时、交互过程中渲染缓慢——这些都需要 run_stress_test / run_simulation不是静态分析。

如果你想在氛围检查的基础上进行更深入的报道：将调查结果输入 run_iterative_fix_loop 对于经过测试验证的应用程序，或升级到Snyk/Semgrep/GitHub Advanced Security以获取合规用例。

氛围检查与替代方案

如果你的目标是“在我提交之前，什么坏了？”，那么氛围检查在延迟方面获胜。如果你的目标是“合规+供应链审计”，请使用专用工具。

何时不使用测试精灵

• 生产闸门试运行。 测试精灵是为 发展 反馈回路。对于运输决策，请使用您端到端控制的适当CI。
• 你的团队必须亲自审查每一行代码。 循环的工作是 提出并应用 修复；如果每次修理都需要人的眼睛，那就离开 autoApply: false （默认设置），并仅将其用作修复建议生成器。
• 无备份/无版本控制情况。 testgenie的自动回滚是最好的努力，需要存在每个文件的备份。始终在git工作树中运行。

比较

范围说明： diagnose_project autoFix: true 回滚语法验证 失败(applyFix.ts:185-202)但确实如此 不 重新运行测试，因此 无法检测到测试回归。用于测试驱动的回滚使用 run_iterative_fix_loop。参见 安全.md §2.4.

测试精灵 用途 Jest、Detox和 xcodebuild test 在幕后，它位于编排层，而不是测试运行器层。

已知限制

• 平台语法检查降级。 对于Swift/Kotlin/Java/Dart，我们在 -typecheck 模式。如果编译器不在PATH上，我们就回到大括号平衡验证和表面 downgraded: true 在结果中。安装 swiftc / kotlinc / javac / dart 以进行真正的验证。
• LLM是可选的，并且是门控的。 strategy: 'hybrid' 只有当基于规则的置信度低于阈值时，才会启用LLM。如果没有API密钥，则循环仅基于规则-无故障。
• 存储按每台机器计算。 测试历史/迭代日志实时更新 $TEST_GENIE_STORAGE_DIR （默认为 ~/.test-genie-mcp).未跨机器同步。
• 模拟模式是“模拟”，不是魔法。 run_simulation 回报 可信的 异常，而不是真实的。使用 run_scenario_test （混合）用于实际设备运行。

配置

从v2.x迁移

• run_full_automation 仍然有效。这 confirmMode / autoFix 为了兼容性保留了选项，但 autoApply: boolean 这是新的方式吗 — autoApply: true 等同于 confirmMode: 'auto'.
• 子进程强化意味着平台工具现在拒绝包含shell元字符的方案/设备/包名称参数。如果你的CI传递了看起来很奇怪的值，请先对其进行消毒。
• 看 更改日志.md 查看完整的突破性更改列表+迁移食谱。

路线图

• 基于LLM的修复方案 投票 （多项建议→ 按语法选择最佳值+重新测试增量）
• 多仓库同步（从一个MCP调用并行运行N个仓库的循环）
• 一种“监视模式”，在文件保存时运行循环
• 更好的排毒/大师工件摄取（将视频链接到迭代日志中）

贡献

欢迎提出问题、PR和想法——请参阅 贡献.md （TODO）。代码存在于 src/，测试 tests/.快跑 npm test 在发送PR之前。

维护者

@博物馆-代码空间 --龚。

许可证

麻省理工学院——见 许可证.