从 GitHub 拉取请求生成测试
3 分•作者: Aamir21•5 个月前
我一直在尝试一些有趣的东西。<p>AI 编码工具可以非常快速地生成代码，但它们几乎从不生成完整的端到端测试覆盖率。它们创建了大量的测试，主要是单元测试和集成测试，但缺少真实的用户场景。在我们查看的许多代码库中，一旦团队开始使用 Copilot 风格的工具，或者将这项工作留给测试人员作为一项单独的任务，新代码与少量高质量 e2e 测试的比例就会急剧下降。<p>所以我尝试了一种不同的方法。<p>该系统读取一个拉取请求，并：<p>• 分析更改的文件
• 识别未覆盖的逻辑路径 - 使用依赖关系图（一个代码库或多个代码库）
• 通过用户故事或需求理解上下文（在 PR 中作为注释提供）
• 生成测试场景
• 生成与 PR 关联的 e2e 自动化测试<p>此外，如果用户可以连接到他们的 CMS 或 TMS，那么也可以将其拉入。（内部我使用 graphRAG，但这将在另一篇文章中讨论）<p>示例工作流程：<p>1. 提交 PR
2. 系统读取差异 + 链接的 Jira 票据
3. 生成缺失的测试和覆盖率报告<p>在早期的实验中，该系统始终发现了开发人员遗漏的边缘情况。<p>示例输出：<p>代码引用 | 需求 ID | 需求 / 验收标准 | 测试类型 | 测试 ID | 测试描述 | 状态<p>src/api/auth.js:45-78 | GITHUB-234 / JIRA-API-102 | API 应该为无效令牌返回 400 | 集成 | IT-01 | 验证无效令牌的响应 | 通过<p>很好奇其他人是如何思考这种可追溯性的。我也是一名开发人员，所以我很谨慎，只向开发人员展示这些内容，并且只有开发人员才能将其向其他人公开，否则他可以直接采取纠正措施。
查看原文
I’ve been experimenting with something interesting.<p>AI coding tools generate code very quickly, but they almost never generate full end to end test coverage. they create a ton of tests mostly unit and intergations but real user scenarios are missing. In many repos we looked at, the ratio of new code vs small number of high quality e2e tests dropped dramatically once teams started using Copilot-style tools or is left for testers as a separate job.<p>So I tried a different approach.<p>the system reads a pull request and:<p>• analyzes changed files
• identifies uncovered logic paths - using dependency graph (one repo or multi-repo)
• Understand the context via user story or requirements (given as a comment in PR)
• generates test scenarios
• produces e2e automated tests tied to the PR<p>in addition if a user can connect with their CMS, or TMS then it can be pulled into as well. (internally i use graphRAG but that is for another post)<p>Example workflow:<p>1. Push a PR
2. System reads diff + linked Jira ticket
3. Generates missing tests and coverage report<p>In early experiments the system consistently found edge cases that developers missed.<p>Example output:<p>Code Reference| Requirement ID | Requirement / Acceptance Criteria |Test Type Test ID | Test Description |Status<p>src/api/auth.js:45-78 | GITHUB-234 / JIRA-API-102 | API should return 400 for invalid token| Integration| IT-01 | Validate response for invalid token Pass<p>Curious how others are thinking about this kind of traceability. I am a developer too so i am sensitive to only show this to developer and only developer can make it visible to other folks otherwise he can just take the corrective action.