請就技術層面進行測試

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

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

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

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

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

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

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

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

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

測試是否值得

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

不要測試所有東西。

不要測試實作詳細資料

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

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

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

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

模擬:不要失去控制權

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

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

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

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

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

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

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

測試細節:注意事項

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

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

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

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

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

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

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

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

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

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