文章介绍了如何通过使用Claude Code SDK优化端到端（E2E）测试流程，将测试时间减少84%。传统E2E测试耗时且脆弱，通常只在夜间运行，导致问题难以及时发现。通过仅运行与代码变更相关的E2E测试，可以在10分钟内获得结果，提前捕捉问题，确保主分支始终稳定。虽然glob模式可以初步实现这一目标，但其维护成本较高，仍需进一步优化。

使用Claude Code SDK将端到端测试时间减少84%

端到端（E2E）测试位于测试金字塔的顶端，因为它们速度慢、脆弱且昂贵。然而，它们也是唯一能够完全验证跨系统用户工作流程是否正常运行的测试。由于时间限制，大多数团队选择在夜间运行E2E测试，以避免持续集成（CI）瓶颈。但这意味着错误可能会进入生产环境，并且由于需要隔离根本原因的变更过多，修复起来更加困难。

那么，如果我们能够仅为特定代码变更运行相关的E2E测试呢？ 这样，我们可以在不到10分钟内获得结果，在错误发布之前捕获它们，并保持主分支始终干净。

实现这一目标的第一步是使用glob模式。我们通过匹配文件路径来告诉系统测试哪些内容发生了变化。然而，glob模式非常有限，随着代码库的演进，它们需要不断维护。更重要的是，它们覆盖的范围太广。例如，对components/Button.tsx的更改可能需要触发涉及按钮交互的每个E2E测试，具体取决于更改的深度。

那么，我们如何确定哪些E2E测试应该为给定的拉取请求（PR）运行，同时确保覆盖率和精确性呢？我们需要覆盖率，因为遗漏关键测试可能会让错误进入生产环境。同时，我们也需要精确性，因为运行显然会通过的测试只会浪费时间和资源。

Claude Code采用了一种根本不同的方法，其关键区别在于工具调用。Claude Code不会尝试处理整个代码库，而是战略性地检查特定文件，搜索模式，跟踪依赖关系，并逐步构建对变更的理解。

为了成功选择E2E测试，Claude需要知道PR的修改、E2E测试和代码库结构。我们可以通过精心设计的提示将这些信息结合起来。首先，我们使用git diff命令获取分支的变更，并通过添加--minimal --ignore-all-space和--diff-filter=ACMR来聚焦于实际的代码变更，而不是空格噪音。此外，我们还需要排除一些大文件，如package.lock，以保持可管理性。

接下来，我们动态读取测试配置文件（如wdio.conf.ts），以获取当前的测试套件配置。然后，我们构建一个精确的提示，要求Claude Code根据git diff和可用的E2E文件，决定哪些测试应该运行。我们设置了明确的边界，要求Claude Code只运行列出的测试，并在有疑问时包含测试。

最终，我们通过一个复杂的bash命令将所有这些信息传递给Claude，并生成一个test-recommendations.json文件，其中包含要运行的测试列表和解释。

这一解决方案的效果超出了预期。我们过去运行所有核心测试需要44分钟，而现在大多数PR的E2E测试在不到7分钟内完成，即使对于较大的变更也是如此。尽管Claude Code有时会运行比实际需要更多的测试，但这总比遗漏测试要好。

成本方面，该解决方案每月每名贡献者大约花费30美元。尽管价格较高，但它实际上节省了移动设备农场运行器的成本，并且随着模型的降价，预计这些成本会进一步下降。

总的来说，我们节省了资金、开发人员时间，并防止了错误进入生产环境，因此这是一个三赢的局面。

评论主要围绕使用LLM（如Claude Code）优化E2E测试的可行性和有效性展开，观点分为支持和反对两派。

支持观点： 1. LLM的跨语言和跨技术栈优势：brynary认为LLM可以替代传统的静态分析和运行时数据收集，实现跨语言和跨技术栈的测试优化，且只需最小修改。 - "This approach substitutes the intelligence of the LLM to make educated guesses about what tests execute." - "the same technique could be applied to any language or stack with minimal modification."

2. 节省时间和成本：golergka认为在PR阶段不必运行所有E2E测试，概率性解决方案是可接受的，尤其是在失败率较低的情况下。
   • "But there really is no need to run all E2E suite on every PR."
   • "the failure mode of this system, where PR automation failed to flag a breakage, is acceptable if it’s rare enough."

反对观点： 1. 测试覆盖率的降低：meindnoch和ares623指出，LLM选择性运行测试会降低E2E测试的覆盖率，可能遗漏关键测试。 - "You’ve reduced the e2e test coverage by only running those tests that the LLM tells you to run." - "you want to test unrelated parts of the system that might have broke."

2. LLM的不可靠性：jryio和gregorriegler认为LLM的解决方案不够可靠，传统的确定性方法（如Test Impact Analysis）更为合适。

   • "This is a hacky joke. No sane engineer would ever sign off on this."
   • "This is called Test Impact Analysis and it is something worth making deterministic."

3. 成本与复杂性：davemo认为优化测试的努力应放在手动或LLM辅助的测试审计上，而不是依赖LLM进行测试选择。

   • "All of that effort would be much better directed at doing a manual (or LLM-assisted) audit of the E2E tests."
   • "we’re often paying through the nose in costs (complexity, actual dollars spent on CI services)."

其他观点： 1. 测试优先级与分布式测试：duncanfwalker和jaguar75建议优先运行可能失败的测试，并采用分布式测试策略以加快反馈周期。 - "It would be interesting to see if it could be used to prioritise tests." - "Ideally I would shift to having a very small suite of E2E tests that can be run for every PR."

2. 验证与基准测试：politelemon和vladdoster强调需要对LLM的输出进行验证，并考虑其他模型和基准测试。
   • "Without a baseline, as any tester would tell you, the LLM output has been trusted without checking."
   • "Have you tried other models? Or thought about using Output of different models and using combining the output if they have a delta."

总结：评论中对使用LLM优化E2E测试的观点存在分歧，支持者认为其跨语言和节省时间的优势显著，而反对者则担忧测试覆盖率的降低和LLM的不可靠性。