跳转到主要内容

使用 Devin 提升代码覆盖率

大多数生产环境中的应用都没有达到 100% 的代码覆盖率。工程团队必须严格划分优先级,通常会把精力集中在关键路径上编写测试,以最大化投入产出比。Devin 可以通过分析代码库中现有测试套件的风格和结构,弥补这一差距,提升那些虽然不是最关键但仍然很重要的函数的覆盖率。 在这个示例中,我们将使用一个基于 RealWorld 规范的开源 TypeScript 示例应用。该项目已经包含了一些测试,但覆盖率并不全面:https://github.com/SeuRonao/realworld-express-prisma 你可以在这里查看本次 Run 的完整过程,或者继续阅读本文余下内容,逐步了解 Devin 的处理流程。我们将重点展示 Devin 的 Workspace 中的不同部分,例如 Editor 和 Shell。

初始提示

我们首先用一个简单的提示开始本次 Run,指示 Devin 设置开发环境并评估我们应用现有的代码覆盖率:
Devin
在其 Shell 中,Devin 首先从 GitHub 克隆我们的仓库,解析 README 文件,并在本地环境中安装项目依赖。
Devin
接着 Devin 使用其内置编辑器创建 .env 文件,以便应用可以在本地运行。与 Devin 协作时,你也可以自行打开 VS Code 进行手动编辑,或审查 Devin 正在处理的文件。
Devin

建立覆盖率基线

接下来 Devin 会在它的 Shell 中运行测试套件。Devin 的一大优势在于,它不仅可以为你的团队修改或创建代码,还可以直接在它的 Browser 和 Terminal 中操作,对你的代码库、开发环境,甚至正在运行的应用执行更高层次的交互。
Devin
下面我们可以看到 Devin 如何理解并将它在 Shell 中得到的结果整理到我们的对话中,使其更加易于阅读并提炼出关键信息。
Devin

制定改进计划

现在我们可以开始着手当前的核心任务:提高代码覆盖率。看起来 profileViewer.ts 是一个很好的起点,因为它在默认情况下几乎没有任何覆盖率。我们让 Devin 规划下一步操作,它会在整个过程中向我们汇报当前的进展。
Devin
Devin 能够读取现有文件,根据已有功能判断我们可能需要实现哪些测试用例,然后在无需任何人工干预的情况下为我们实际编写这些新测试。完成新测试用例的实现后,Devin 会向我们给出它所做更改的最终总结:
Devin

代码评审

Devin 也会把新文件分享给我们,这样我们就可以下载并进行评审。或者,我们也可以让 Devin 使用这个新文件直接在 GitHub 上创建一个 Pull Request,这样它就可以作为我们常规代码评审流程的一部分来查看。我决定直接在 Devin 内置的编辑器里审查它,这样就不用下载文件了。
Devin
整体来看这些改动不错,但我们还想确保没有遗漏任何运行时 bug,所以我们让 Devin 再次运行测试套件,并将结果反馈给我们。
Devin
测试按预期运行,我们的整体覆盖率也从函数的 28.57% 提升到了 57.14%,这正是我们想要达成的目标。整个实现过程 Devin 实际工作时间不到 10 分钟,尽管我们在中途离开了一段时间,之后才给 Devin 提供下一组指令。你也可以通过把这项繁琐的工作交给 Devin,来提高测试覆盖率,并从工程团队的待办事项中剔除这类任务。 如果你经常回到 Devin 这里来提升代码覆盖率,你甚至可以把这个 Prompt 整理成一个详细的 Playbook,这样就可以很方便地为应用程序的不同部分发起新的 Run。如果你想进一步了解 Devin 擅长处理哪些类型的 Prompt,可以在文档中阅读我们的一些示例