介绍
让我在这篇博客的前言中说，这个与我的其他博客不同，在这些博客中我能够逐步完成完成任务的步骤。相反，这更多地反映了我在尝试向我的项目 gimme_readme 添加测试时遇到的挑战，以及我在此过程中学到的关于测试 llm 支持的应用程序的知识。
背景
本周，我和我的开源开发同学的任务是向包含大型语言模型 (llm) 的命令行工具添加测试。乍一看这似乎很简单，但它让我陷入了一个我没有预料到的测试复杂性的兔子洞。
我的测试之旅
最初的方法
当我第一次构建 gimme_readme 时，我使用 jest.js 添加了一些基本测试。这些测试相当简单，主要关注：
- 验证函数输出
- 检查基本错误处理
- 测试简单的实用函数
虽然这些测试提供了一些覆盖范围，但它们并没有测试我的申请中最关键的部分之一：llm 交互。
挑战：测试 llm 交互
当我尝试添加更全面的测试时，我对我的应用程序如何与法学硕士进行通信有了一个有趣的认识。最初，我认为可以使用 nock.js 来模拟对这些语言模型的 http 请求。毕竟，这就是 nock 的擅长之处 - 拦截和模拟 http 请求以进行测试。
但是，我发现我使用llm的方式让我很难使用nock编写测试。
sdk 与直接 http 请求的困境
这就是事情变得有趣的地方。我的应用程序使用 llm 服务（例如 google 的 gemini 和 groq）提供的官方 sdk 客户端。这些 sdk 充当抽象层，在幕后处理所有 http 通信。虽然这使得代码更干净、更容易在生产中使用，但它带来了有趣的测试挑战。
考虑这两种实现 llm 功能的方法：
使用固定的 Next.js/Tailwind/Prisma 技术栈构建并记录独立 SaaS 项目，仅将 FastAPI 用于 Python 工作负载，并遵循严格的架构规范。
// Approach 1: Using SDK
const groq = new Groq({ apiKey });
const response = await groq.chat.completions.create({
messages: [{ role: "user", content: prompt }],
model: "mixtral-8x7b-32768"
});
// Approach 2: Direct HTTP requests
const response = await fetch('https://api.groq.com/v1/completions', {
method: 'POST',
headers: {
'Authorization': `Bearer ${apiKey}`,
'Content-Type': 'application/json'
},
body: JSON.stringify({
messages: [{ role: "user", content: prompt }],
model: "mixtral-8x7b-32768"
})
});
sdk 方法更简洁，提供了更好的开发人员体验，但它使得像 nock 这样的传统 http 模拟工具不太有用。 http 请求发生在 sdk 内部，这使得它们更难被 nock 拦截。
经验教训
尽早考虑测试策略：在 sdk 和直接 http 请求之间进行选择时，请考虑如何测试实现。有时，“更干净”的生产代码可能会使测试更具挑战性。
-
sdk 测试需要不同的工具：使用 sdk 时，需要在 sdk 级别而不是 http 级别进行模拟。这意味着：
- 模拟整个 sdk 客户端
- 专注于 sdk 的接口而不是 http 请求
- 使用 jest 的模块模拟功能而不是 http 拦截器
便利性和可测试性之间的平衡：虽然 sdk 提供了出色的开发人员体验，但它们可能会使某些测试方法变得更加困难。在构建应用程序时值得考虑这种权衡。
前进
虽然我还没有完全解决我的测试挑战，但这段经历教会了我关于通过 sdk 测试依赖于外部服务的应用程序的宝贵经验。对于构建类似应用程序的任何人，我建议：
- 在 sdk 和直接 api 调用之间进行选择时考虑测试策略
- 如果使用 sdk，请计划在 sdk 级别而不是 http 级别进行模拟
- 考虑在 sdk 周围编写薄包装器，使它们更易于测试
- 为可能参与该项目的其他人记录测试方法
结论
测试 llm 应用程序带来了独特的挑战，特别是在平衡 sdk 等现代开发便利性与彻底测试的需要时。虽然我仍在努力提高 gimme_readme 的测试覆盖率，但这次经历让我更好地了解了如何在涉及外部服务和 sdk 的未来项目中进行测试。
还有其他人在测试使用 llm sdk 的应用程序时遇到过类似的挑战吗？我很想在评论中听到您的经验和解决方案！
