我实际上是如何首先使用 GitHub Copilot 编写测试的（不欺骗自己）
测试驱动开发失败是因为编写测试比编写代码慢。副驾驶翻转了数学，这就是它真正起作用的工作流程。
每个开发人员都相信测试，就像每个人都相信牙线一样，测试优先的开发因同样的原因而失败：当你处于流程状态时，编写测试感觉就像停下来做文书工作。副驾驶为我改变了数学，不是让测试变得愉快，而是让测试足够快，以至于文书工作的反对意见消失了。这是它真正有效的工作流程。
诀窍是将测试编写为规范，并让 Copilot 执行样板文件。在接触实现之前，我编写了一个失败的测试，其中包含测试名称中的场景以及用简单语言描述预期行为的注释。 Copilot 以令人惊讶的能力填写断言、模拟和设置，因为测试文件正是它擅长的模式代码。我的工作缩小到审查测试是否测试了正确的东西，这是一个判断，而不是打字。
对场景进行批处理，一次一个函数。我在开始之前列出了案例、愉快的路径、空输入、边界、错误，然后让 Copilot 一次性生成它们并一起检查一组。将五个测试作为一组进行审查，可以发现逐一审查时所遗漏的情况：缺失的情况，通常是您的代码库之前遇到过的奇怪情况。我的飞行前提示现在包括一条注释行，列出了该模块中过去的生产事件，因为除非您告诉它，否则模型无法知道该上下文。
The honest part of test-first with AI is knowing where it misleads.副驾驶会很高兴地编写一个测试来反映您的错误假设，而建立在共同误解之上的绿色套件比没有套件更糟糕，因为它可以防御错误。解药是廉价且不可协商的：在实施之前，运行测试并观察它因正确原因而失败，然后故意破坏断言中的预期输出并确认测试捕获它。 Thirty seconds per test that keeps the suite honest.
这在实践中给我带来了什么：覆盖无聊的路径、输入验证和错误处理，我从来没有写过这些，因为成本下降到接近于零。它没有给我带来什么：一个跳过思考代码应该做什么的借口，无论如何，测试优先总是应该有帮助的。红绿重构节奏完好无损； Copilot 刚刚删除了编写红色测试感觉像是征税的部分。