从GitHub拉取请求生成测试
我一直在尝试一些有趣的东西。<p>AI 编码工具能够非常快速地生成代码，但几乎从未生成完整的端到端测试覆盖率。它们创建了大量的测试，主要是单元测试和集成测试，但缺少真实用户场景。在我们查看的许多代码库中，一旦团队开始使用 Copilot 风格的工具，新代码与少量高质量的端到端测试的比例急剧下降，或者这些工作被留给测试人员作为单独的任务。<p>因此，我尝试了一种不同的方法。<p>该系统读取拉取请求并：<p>• 分析更改的文件
• 识别未覆盖的逻辑路径 - 使用依赖图（单个代码库或多个代码库）
• 通过用户故事或需求理解上下文（作为 PR 中的评论提供）
• 生成测试场景
• 产生与 PR 关联的端到端自动化测试<p>此外，如果用户能够连接到他们的内容管理系统（CMS）或翻译管理系统（TMS），那么这些信息也可以被拉入。（我内部使用的是 graphRAG，但那是另一个话题）<p>示例工作流程：<p>1. 提交一个拉取请求
2. 系统读取差异 + 关联的 Jira 票据
3. 生成缺失的测试和覆盖率报告<p>在早期实验中，该系统始终能够发现开发人员遗漏的边缘案例。<p>示例输出：<p>代码引用 | 需求 ID | 需求/验收标准 | 测试类型 | 测试 ID | 测试描述 | 状态
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.