加速单元测试生成并提高代码质量

最近，我有机会深入研究 Early，一个专为自动单元测试生成而设计的 AI 代理。作为经常使用 TypeScript 和 ExpressoTS Framework 的人，我很想知道 Early 如何简化我的工作流程。我决定测试他们在我正在开发的名为 @expressots/share 的新 NPM 库上构建的 vscode 扩展。

初步印象

Early 让我印象深刻的第一件事是它能够为我现有的代码库自动生成单元测试。我可以专注于改进生成的测试并提高代码的健壮性和可测试性，而不是从头开始编写测试。这种转变极大地加速了我的发展进程。我注意到的另一个有趣的方面是，我生成的 83% 的代码没有进行任何调整，它开箱即用，并增加了我的代码覆盖率。为我节省了很多时间。

节省时间并扩大覆盖范围

在短短 8.5 小时内，我设法：

• 生成大约 3,000 行代码的单元测试。
• 修复问题并增强代码可测试性。
• 通过 96 次测试实现 88% 的总代码覆盖率。

我能在一天之内完成这一切，这一事实是了不起的。单元测试的理想场景是在实际开发功能时进行测试。我是在我已经有了一个库之后才这样做的，因此需要进行一些调整才能使代码可测试。

积极成果

自动生成边缘案例测试。例如，它为涉及空字符串的场景生成单元测试，即使需要参数：

export function printSuccess(message: string, component: string): void {
  stdout.write(chalk.green(`${message}:`, chalk.bold(chalk.white(`[${component}] ✔️\n`))));
}

最初，我不会在如此简单的函数中创建空字符串的测试。然而，Early 的方法促进了防御性编程实践，促使我处理我可能忽略的边缘情况。

检测潜在问题

在优化生成的测试时，我遇到了类型不匹配的问题：

问题：jest.fn() 返回 any，但 process.exit 从不返回，导致 TypeScript 中类型不匹配。
解决方案：修改mock以匹配process.exit签名，确保类型正确性。
这一发现促使我调整我的代码以获得更好的类型安全性，突出显示 Early 如何帮助识别否则可能会被忽视的微妙问题。

需要改进的地方

尽管总体体验积极，但我遇到了一些挑战，如果解决这些挑战，可以提高 Early 的可用性：

• 库版本兼容性。在某些情况下，早期生成的测试使用已弃用的 Jest 方法，例如：

使用 Jest 29.7

expect(Compiler.loadConfig()).rejects.toThrowError("process.exit() was called with code 1");

//修正版本

expect(Compiler.loadConfig()).rejects.toThrow("process.exit() was called with code 1");

• 测试生成的自定义选项 虽然为边缘情况生成测试是有益的，但在某些情况下，可能没有必要：

观察：为每个可能的输入（包括空字符串）生成测试有时可能有点过分。

建议：引入自定义测试生成级别的选项，允许开发人员根据需要选择防御性编程测试。

• VSCODE 扩展中的用户界面增强功能 在 Early 和其他工具之间导航突出了一些 UI 限制：

测试结果可见性：我必须在 Early 和 Jest 之间切换才能查看哪些测试通过或失败。

文件树状态：从其他应用程序切换回来时，早期的项目层次结构会崩溃，需要我反复重新打开文件夹。
建议：改进 UI 以在 Early 中显示测试结果，反映 Jest 的结构。维护文件树的状态也将增强用户体验。

• 模拟和类型安全 jest.fn() 返回 any 的问题表明需要更精确的模拟：

观察：在模拟中使用任何类型都可能导致类型不匹配并可能掩盖错误。
建议：改进模拟生成以使用准确的签名，促进更好的类型安全并减少手动更正的需要。

结论

总的来说，我在 Early 的经历非常积极。该工具显着加速了我的单元测试过程，使我能够专注于改进测试，而不是从头开始编写测试。它还鼓励我考虑边缘情况并提高代码的稳健性。

需要改进的领域相对较小，主要围绕增强可用性和定制化。解决这些问题将使该工具在软件开发中变得更加强大。

感谢早期团队的出色工作！我很高兴看到该工具如何发展，并很乐意继续提供反馈以帮助进一步完善它。