請就技術層面進行測試

決定要測試的內容，以及可排除的內容。

Ramona Schwering

上一篇文章涵蓋測試案例的基本概念和應包含的內容。本文將從技術層面進一步說明如何建立測試案例，詳細說明每項測試應包含的項目以及應避免的內容。基本上，您可以從「測試內容」或「不應測試的項目」這幾個古老問題中找到答案。

要測試與不要測試的內容。

一般指南和模式

請特別注意，無論是執行單元、整合或端對端測試，特定模式和重點仍至關重要。這些原則可以或應用於兩種測試類型，因此適合從這些測試著手。

保持簡單

撰寫測試時，最重要的一點是保持簡單。請務必考量大腦的容量。主要實際工作環境程式碼佔用大量空間，因爲其他作業複雜而有更多空間。這對於測試尤其重要。

如果可用空間減少，測試的難度就會比較大。因此，以簡單明瞭的方式測試相當重要。事實上，Yoni Goldberg 的 JavaScript 測試最佳做法強調「Golden Rule」的重要性，測試就像是助理，不要像複雜的數學公式一樣。換句話說，您應先瞭解測試的意圖。

別讓測試變得複雜，客戶不應這樣感覺。

不論測試類型為何，建議您都希望能簡化所有類型的測試。事實上，測試越複雜，其越重要。進行測試的其中一種方法是採用平面測試設計，測試的設計盡可能保持簡單，並且只測試必要的內容。也就是說，每項測試只能包含一個測試案例，測試案例應著重於測試單一特定功能或功能。

從這個觀點思考：讀取失敗的測試應可輕易找出問題所在。這就是為什麼測試保持簡單明瞭也很重要。這樣做可以在問題發生時快速找出並加以修正。

測試是否值得

平面測試設計也能鼓勵聚焦，並確保測試有意義。請注意，建議您不要只是為了提高涵蓋率而建立測試，因為這類測試必須有用途。

不要測試所有東西。

不要測試實作詳細資料

測試中常見的問題之一，就是測試通常是用來測試實作詳細資料，例如在元件或端對端測試中使用選取器。導入作業詳情是指程式碼使用者通常不會使用、查看或甚至知道的內容。這可能會導致測試發生兩個主要問題：偽陰性和偽陽性。

如果測試失敗，即使測試的程式碼正確無誤，仍會發生偽陰性的情形。如果實作詳細資料因重構應用程式程式碼而發生變更，就可能發生這種情況。另一方面，即使測試的程式碼有誤，仍會在測試通過時發生誤判。

解決這個問題的一個方法，就是考慮不同類型的使用者。使用者和開發人員的做法各有不同，且可能會以不同的方式與程式碼互動。規劃測試時，請務必考量使用者會看到或互動的內容，並使測試視這些因素 (而非實作詳細資料) 進行。

舉例來說，選擇變更較不易的選取器能讓測試更加可靠：data-attributes，而非 CSS 選取器。詳情請參閱 Kent C. 阿德'斯有關這個主題的文章，或密切留意後續資訊，我們稍後會發布有關這個主題的文章。

模擬：不要失去控制權

模擬是單元測試中 (有時用於整合測試) 的廣泛概念。這牽涉到建立假資料或元件，以模擬可完全控制應用程式的依附元件。以便進行隔離測試。

在測試中使用模擬有助於提升可預測性、關注點分離原則和效能。另外，如果需要人為介入的檢測 (例如護照驗證)，請務必以模擬畫面隱藏。基於上述所有原因，建議您考慮使用模擬工具。

同時，模擬可能影響測試的準確率，因為模擬結果是模擬的，而非實際的使用者體驗。因此，使用模擬和虛設常式時，請特別留意。

您是否要模擬端對端測試？

通常不會。不過，因為模擬內容有時會有生命儲存，所以不要完全排除。

試想一下這個情境：您正在編寫涉及第三方付款服務供應商服務的測試。這邊的 帳戶是由系統提供的沙箱環境，系統不會執行任何真正的交易。不幸的是，沙箱故障，導致測試失敗。解決方式必須由付款服務供應商進行。請等待供應商解決問題。

在這種情況下，較有助於減少對您無法控制的服務依附性。我們還是建議在整合或端對端測試中謹慎使用模擬功能，因為這樣會降低測試的信賴水準。

測試細節：注意事項

那麼，測試包含什麼？測試類型之間是否存在差異？讓我們進一步瞭解針對主要測試類型特別設計的部分。

良好的單元測試應具備哪些條件？

理想且有效的單元測試應該：

  • 專注在特定層面。
  • 獨立作業。
  • 涵蓋小規模場景。
  • 請使用描述性名稱。
  • 遵守 AAA 模式 (如適用)。
  • 保證全面測試的涵蓋範圍。
是否 ✅ 不要 ❌
盡量減少測試數量。每個測試案例僅測試一項項目。 針對大型單元編寫測試。
請務必將測試獨立出來，並模擬出廣告單元以外的用途。 加入其他元件或服務。
讓測試各自獨立。 依據先前的測試或分享測試資料。
涵蓋不同的情境和路徑。 請把自己做到最好的路徑，或排除測試目標。
使用描述性的測試標題，以便立即查看測試內容。 僅依函式名稱進行測試，避免使用足夠的描述性結果：testBuildFoo() 或 testGetId()。
請盡量擴大程式碼涵蓋範圍，或擴大測試案例範圍，特別是在這個階段。 從每個類別到資料庫 (I/O) 層級進行測試。

良好的整合測試必須具備哪些條件？

理想的整合測試與單元測試同樣具備一些條件。不過，你還需要考量一些額外重點。良好的整合測試應該：

  • 模擬元件之間的互動。
  • 請講解真實情境，並運用模擬或虛設常式。
  • 考量成效。
是否 ✅ 不要 ❌
測試整合點：確認每個單位在整合後都能流暢地搭配運作。 單獨測試每個單元，這就是單元測試的目標。
測試真實情境：使用從實際資料衍生的測試資料。 使用重複的自動產生的測試資料，或是無法反映實際使用情況的其他資料。
針對外部依附元件使用模擬和虛設常式，持續控管完整測試。 為第三方服務建立依附元件，例如向外部服務發出網路要求。
在每次測試前後，使用清除處理常式。 請避免在測試中使用清理措施，否則由於缺少適當的測試隔離機制，這可能會導致測試失敗或偽陽性。

良好的端對端測試包含哪些條件？

完整的端對端測試應符合下列條件：

  • 複製使用者互動。
  • 涵蓋重要情境。
  • 橫跨多個圖層。
  • 管理非同步作業。
  • 驗證結果。
  • 將成效納入考量。
是否 ✅ 不要 ❌
使用以 API 為準的快速鍵。瞭解詳情。 為每個步驟使用 UI 互動，包括 beforeEach 掛鉤。
在每次測試前使用清除處理常式。與單元和整合測試相比，應更謹慎執行測試隔離，因為這類副作用的風險較高。 每次測試後，忘了清理。如未清除剩餘狀態、資料或連帶影響，會影響之後執行的其他測試。
將端對端測試視為系統測試。也就是說，您必須測試整個應用程式堆疊。 單獨測試每個單元，這就是單元測試的目標。
應盡量減少或不要模擬測試。如要模擬外部依附元件，請務必謹慎考慮。 非常仰賴模擬。
考量效能和工作負載等因素，不要在同一個測試中對大型情境進行過度測試。 在不使用快速鍵的情況下處理大型工作流程。