我應該單元測試對$ .ajax的呼叫還是已發送XHR？

Question

假設我有以下方法：

function sendUserDataToServer(userData) {
    // Do some configuration stuff
    $.ajax('SomeEndpoint', userData);
}

在為此功能編寫單元測試時，我可以采用以下兩種方法之一：

為什么我會選擇選項1：它將$ .ajax的功能與代碼分開。 如果$.ajax由於jQuery中的錯誤而中斷，則不會在我的單元測試結果中產生假負數。

為什么選擇選項2：為什么我決定要使用jQuery之外的其他庫來發送XHR，所以不必更改單元測試來檢查其他方法。 但是，如果該庫中存在錯誤，我的單元測試將失敗，並且我不一定會立即知道它是該庫，而不是我的實際代碼。

哪種方法正確？

Answer 1

您的第一個選擇是正確的。 單元測試的目的是雙重的

您的問題是關於與$.ajax的交互作用，因此此測試的目的是確認它可以與其協作者正確對話。

如果您選擇選項1，這正是您要執行的操作。 如果使用選項2，則說明您正在測試第三方庫，而不是在正確執行通信協議。

您應該同時進行兩個測試。 盡管有些人可能將其稱為集成測試，但第二個測試可能足夠快以與單元測試一起使用。 該測試表明您正在正確使用庫來創建要創建的對象 。 同時擁有這兩者將使您能夠區分代碼中的錯誤和庫，如果存在庫錯誤會導致系統中的其他內容出現故障，這將非常有用。

Answer 2

我的看法：在單元測試中，選項1更正確。

單元測試應僅測試代碼單元。 在您的情況下，這將是受您控制的JavaScript（例如，函數內部，類或命名空間中的邏輯，具體取決於函數的上下文）。

您的單元測試應該模擬jQuery調用，並相信它可以正常工作。 進行真正的AJAX調用很好，但是這將是集成測試的一部分。

關於什么是單元測試和什么不是單元測試，請參見此答案。

順便說一句，第三種方法是通過自定義代理類進行AJAX調用，該類可以在測試中模擬，但也允許您切換使用的庫。

Answer 3

我將使用選項1，但選擇使測試最容易理解的選項。

您在代碼中依賴jQuery，因此您無需擔心它實際上是否如您指出的那樣起作用。 我發現，當您指定參數和響應並讓您的代碼對其進行處理時，它可使測試變得更干凈。 您還可以指定應輕松使用哪個回調（ success或error ）。

至於從jQuery更改庫。 如果更改代碼，則測試將失敗。 您可能會爭辯說您的行為現在有所不同。 是的，您正在進行Ajax調用，但是具有不同的依賴關系。 並且您的測試應進行更新以反映此更改。

兩種方法都是正確的。 如果您正在創建自己的用於發送Ajax調用的包裝器，則可能有必要截獲XHR請求或手動創建該請求並自行發送。 選擇使您的測試最容易理解和維護的選項。

Answer 4

最重要的是測試您自己的代碼。 將業務邏輯與IO代碼和您的業務邏輯分開。 在那之后，您應該擁有沒有任何邏輯來執行實際IO的方法（與您的示例完全相同）。 現在：您應該測試該方法嗎？ 這取決於。 測試是為了讓您感到更安全。

如果您真的擔心jQuery會失敗，並且您無法承受這種不可能的情況，那就需要對其進行測試。 但不包含某些模擬庫，而是進行完整的端到端集成測試
如果您不確定是否正確使用jQuery，請執行“學習測試”。 向其傳遞參數，並檢查它產生什么樣的請求。 在這種情況下，模擬測試就足夠了
如果您需要前端和后端之間的合同文檔，則可以選擇是否要測試后端是否符合合同，前端或兩者兼而有之。
但是，如果以上都不適用於您，那么測試外部的，完善的框架不是浪費時間嗎？ jQuery家伙肯定已經測試過了。 您仍然可能需要某種集成測試（自動或手動）來檢查您的前端是否與后端正確交互。 這些測試將覆蓋網絡層