介紹

讓我在這篇部落格的前言中說，這個與我的其他部落格不同，在這些部落格中我能夠逐步完成完成任務的步驟。相反，這更反映了我在嘗試向我的專案 gimme_readme 添加測試時遇到的挑戰(zhàn)，以及我在此過程中學到的關於測試 LLM 支援的應用程式的知識。

背景

本週，我和我的開源開發(fā)同學的任務是為包含大型語言模型 (LLM) 的命令列工具新增測試。乍看之下這似乎很簡單，但它讓我陷入了一個我沒有預料到的測試複雜性的兔子洞。

我的測試之旅

最初的方法

當我第一次建立 gimme_readme 時，我使用 Jest.js 添加了一些基本測試。這些測試相當簡單，主要關注：

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

雖然這些測試提供了一些覆蓋範圍，但它們並沒有測試我的申請中最關鍵的部分之一：LLM 互動。

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

當我嘗試添加更全面的測試時，我對我的應用程式如何與法學碩士進行通信有了一個有趣的認識。最初，我認為可以使用 Nock.js 來模擬對這些語言模型的 HTTP 請求。畢竟，這就是 Nock 的擅長之處 - 攔截和模擬 HTTP 請求以進行測試。

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

SDK 與直接 HTTP 請求的困境

這就是事情變得有趣的地方。我的應用程式使用 LLM 服務（例如 Google 的 Gemini 和 Groq）提供的官方 SDK 用戶端。這些 SDK 充當抽象層，在幕後處理所有 HTTP 通訊。雖然這使得程式碼更乾淨、更容易在生產(chǎn)中使用，但它帶來了有趣的測試挑戰(zhàn)。

考慮這兩種實現(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ā)人員體驗，但它使得 Nock 等傳統(tǒng) HTTP 模擬工具不太有用。 HTTP 請求發(fā)生在 SDK 內(nèi)部，這使得它們更難被 Nock 攔截。

經(jīng)驗教訓

1. 儘早考慮測試策略：在 SDK 和直接 HTTP 請求之間進行選擇時，請考慮如何測試實作。有時「更乾淨」的生產(chǎn)程式碼可能會使測試更具挑戰(zhàn)性。

2. SDK 測試需要不同的工具：使用 SDK 時，需要在 SDK 層級而不是 HTTP 層級進行模擬。這意味著：

   • 模擬整個 SDK 用戶端
   • 專注於 SDK 的介面而不是 HTTP 請求
   • 使用 Jest 的模組模擬功能而不是 HTTP 攔截器

3. 便利性和可測試性之間的平衡：雖然 SDK 提供了出色的開發(fā)人員體驗，但它們可能會使某些測試方法變得更加困難。在建立應用程式時值得考慮這種權衡。

前進

雖然我還沒有完全解決我的測試挑戰(zhàn)，但這段經(jīng)歷教會了我關於透過 SDK 測試依賴外部服務的應用程式的寶貴經(jīng)驗。對於建立類似應用程式的任何人，我建議：

1. 在 SDK 和直接 API 呼叫之間進行選擇時考慮測試策略
2. 如果使用 SDK，請規(guī)劃在 SDK 等級而不是 HTTP 等級進行模擬
3. 考慮在 SDK 周圍編寫薄包裝器，使它們更易於測試
4. 為可能參與該專案的其他人記錄測試方法

結論

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

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

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