跳转到主要内容
大多数生产环境中的应用都没有达到 100% 的代码覆盖率。工程团队必须严格划分优先级,通常会把精力集中在关键路径上编写测试,以最大化投入产出比。Devin 可以通过分析代码库中现有测试套件的风格和结构,弥补这一差距,提升那些虽然不是最关键但仍然很重要的函数的覆盖率。
在这个示例中,我们将使用一个基于 RealWorld 规范的开源 TypeScript 示例应用。该项目已经包含了一些测试,但覆盖率并不全面:https://github.com/SeuRonao/realworld-express-prisma
你可以在这里查看本次 Run 的完整过程,或者继续阅读本文余下内容,逐步了解 Devin 的处理流程。我们将重点展示 Devin 的 Workspace 中的不同部分,例如 Editor 和 Shell。
我们首先用一个简单的提示开始本次 Run,指示 Devin 设置开发环境并评估我们应用现有的代码覆盖率:
在其 Shell 中,Devin 首先从 GitHub 克隆我们的仓库,解析 README 文件,并在本地环境中安装项目依赖。
接着 Devin 使用其内置编辑器创建 .env 文件,以便应用可以在本地运行。与 Devin 协作时,你也可以自行打开 VS Code 进行手动编辑,或审查 Devin 正在处理的文件。
接下来 Devin 会在它的 Shell 中运行测试套件。Devin 的一大优势在于,它不仅可以为你的团队修改或创建代码,还可以直接在它的 Browser 和 Terminal 中操作,对你的代码库、开发环境,甚至正在运行的应用执行更高层次的交互。
下面我们可以看到 Devin 如何理解并将它在 Shell 中得到的结果整理到我们的对话中,使其更加易于阅读并提炼出关键信息。
现在我们可以开始着手当前的核心任务:提高代码覆盖率。看起来 profileViewer.ts 是一个很好的起点,因为它在默认情况下几乎没有任何覆盖率。我们让 Devin 规划下一步操作,它会在整个过程中向我们汇报当前的进展。
Devin 能够读取现有文件,根据已有功能判断我们可能需要实现哪些测试用例,然后在无需任何人工干预的情况下为我们实际编写这些新测试。完成新测试用例的实现后,Devin 会向我们给出它所做更改的最终总结:
Devin 也会把新文件分享给我们,这样我们就可以下载并进行评审。或者,我们也可以让 Devin 使用这个新文件直接在 GitHub 上创建一个 Pull Request,这样它就可以作为我们常规代码评审流程的一部分来查看。我决定直接在 Devin 内置的编辑器里审查它,这样就不用下载文件了。
整体来看这些改动不错,但我们还想确保没有遗漏任何运行时 bug,所以我们让 Devin 再次运行测试套件,并将结果反馈给我们。
测试按预期运行,我们的整体覆盖率也从函数的 28.57% 提升到了 57.14%,这正是我们想要达成的目标。整个实现过程 Devin 实际工作时间不到 10 分钟,尽管我们在中途离开了一段时间,之后才给 Devin 提供下一组指令。你也可以通过把这项繁琐的工作交给 Devin,来提高测试覆盖率,并从工程团队的待办事项中剔除这类任务。
如果你经常回到 Devin 这里来提升代码覆盖率,你甚至可以把这个 Prompt 整理成一个详细的 Playbook,这样就可以很方便地为应用程序的不同部分发起新的 Run。如果你想进一步了解 Devin 擅长处理哪些类型的 Prompt,可以在文档中阅读我们的一些示例。