介紹

讓我在這篇博客的前言中說，這個(gè)與我的其他博客不同，在這些博客中我能夠逐步完成完成任務(wù)的步驟。相反，這更多地反映了我在嘗試向我的項(xiàng)目 gimme_readme 添加測試時(shí)遇到的挑戰(zhàn)，以及我在此過程中學(xué)到的關(guān)于測試 LLM 支持的應(yīng)用程序的知識。

背景

本周，我和我的開源開發(fā)同學(xué)的任務(wù)是向包含大型語言模型 (LLM) 的命令行工具添加測試。乍一看這似乎很簡單，但它讓我陷入了一個(gè)我沒有預(yù)料到的測試復(fù)雜性的兔子洞。

我的測試之旅

最初的方法

當(dāng)我第一次構(gòu)建 gimme_readme 時(shí)，我使用 Jest.js 添加了一些基本測試。這些測試相當(dāng)簡單，主要關(guān)注：

• 驗(yàn)證函數(shù)輸出
• 檢查基本錯(cuò)誤處理
• 測試簡單的實(shí)用函數(shù)

雖然這些測試提供了一些覆蓋范圍，但它們并沒有測試我的申請中最關(guān)鍵的部分之一：LLM 交互。

挑戰(zhàn)：測試 LLM 交互

當(dāng)我嘗試添加更全面的測試時(shí)，我對我的應(yīng)用程序如何與法學(xué)碩士進(jìn)行通信有了一個(gè)有趣的認(rèn)識。最初，我認(rèn)為可以使用 Nock.js 來模擬對這些語言模型的 HTTP 請求。畢竟，這就是 Nock 的擅長之處 - 攔截和模擬 HTTP 請求以進(jìn)行測試。

但是，我發(fā)現(xiàn)我使用LLM的方式讓我很難使用Nock編寫測試。

SDK 與直接 HTTP 請求的困境

這就是事情變得有趣的地方。我的應(yīng)用程序使用由 LLM 服務(wù)（例如 Google 的 Gemini 和 Groq）提供的官方 SDK 客戶端。這些 SDK 充當(dāng)抽象層，在幕后處理所有 HTTP 通信。雖然這使得代碼更干凈、更容易在生產(chǎn)中使用，但它帶來了有趣的測試挑戰(zhàn)。

考慮這兩種實(shí)現(xiàn) LLM 功能的方法：

// 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 方法更簡潔，并提供更好的開發(fā)人員體驗(yàn)，但它使得 Nock 等傳統(tǒng) HTTP 模擬工具不太有用。 HTTP 請求發(fā)生在 SDK 內(nèi)部，這使得它們更難被 Nock 攔截。

經(jīng)驗(yàn)教訓(xùn)

1. 盡早考慮測試策略：在 SDK 和直接 HTTP 請求之間進(jìn)行選擇時(shí)，請考慮如何測試實(shí)現(xiàn)。有時(shí)“更干凈”的生產(chǎn)代碼可能會(huì)使測試更具挑戰(zhàn)性。

2. SDK 測試需要不同的工具：使用 SDK 時(shí)，需要在 SDK 級別而不是 HTTP 級別進(jìn)行模擬。這意味著：

   • 模擬整個(gè) SDK 客戶端
   • 專注于 SDK 的接口而不是 HTTP 請求
   • 使用 Jest 的模塊模擬??功能而不是 HTTP 攔截器

3. 便利性和可測試性之間的平衡：雖然 SDK 提供了出色的開發(fā)人員體驗(yàn)，但它們可能會(huì)使某些測試方法變得更加困難。在構(gòu)建應(yīng)用程序時(shí)值得考慮這種權(quán)衡。

前進(jìn)

雖然我還沒有完全解決我的測試挑戰(zhàn)，但這段經(jīng)歷教會(huì)了我關(guān)于通過 SDK 測試依賴于外部服務(wù)的應(yīng)用程序的寶貴經(jīng)驗(yàn)。對于構(gòu)建類似應(yīng)用程序的任何人，我建議：

1. 在 SDK 和直接 API 調(diào)用之間進(jìn)行選擇時(shí)考慮測試策略
2. 如果使用 SDK，請計(jì)劃在 SDK 級別而不是 HTTP 級別進(jìn)行模擬
3. 考慮在 SDK 周圍編寫薄包裝器，使它們更易于測試
4. 為可能參與該項(xiàng)目的其他人記錄測試方法

結(jié)論

測試 LLM 應(yīng)用程序帶來了獨(dú)特的挑戰(zhàn)，特別是在平衡 SDK 等現(xiàn)代開發(fā)便利性與徹底測試的需要時(shí)。雖然我仍在努力提高 gimme_readme 的測試覆蓋率，但這次經(jīng)歷讓我更好地了解了如何在涉及外部服務(wù)和 SDK 的未來項(xiàng)目中進(jìn)行測試。

還有其他人在測試使用 LLM SDK 的應(yīng)用程序時(shí)遇到過類似的挑戰(zhàn)嗎？我很想在評論中聽到您的經(jīng)驗(yàn)和解決方案！

以上是測試 LLM 應(yīng)用程序：模擬 SDK 與直接 HTTP 請求中的不幸事件的詳細(xì)內(nèi)容。更多信息請關(guān)注PHP中文網(wǎng)其他相關(guān)文章！