要測試哪些項目與「是」測試相反,對於所有團隊來說都是相當重要的問題。測試只是要達成這個目的,但選擇程式碼集不同部分測試優先順序的方式可能並不容易。
決定優先順序的最佳方法是根據程式碼集和團隊的目標而定。但請務必記住,雖然在測試金字塔底部 (例如單元測試) 底部編寫大量程式碼測試所需的時間與頻寬並不需要,但不一定能降低專案的整體風險。
您可以先思考應用程式、網站或程式庫的主要用途,藉此選擇要先測試哪些項目。例如針對網站的重要部分 (也就是構成使用者體驗的核心元件) 編寫元件測試。舉例來說,如果網站允許使用者上傳及管理時間序列資料,開發人員就應該想像及測試使用者可能執行這些工作的不同方式。
另一個優先排序的方法,就是取得最豐富的資訊。如果您的程式碼集有「危險」、「老舊」或不當編寫的負載恐懼,且您的團隊沒有人喜歡參與工作,那麼在進一步忽略程式碼之前,建議您針對該部分建構測試,以使其行為更加一致,或重構並修正問題。這就像是為已組合而成,但仍有資料中心的員工架設鷹架。
維度
雖然我們採用了測試金字塔或其他測試形狀的概念,但這些概念通常只會顯示單一測試維度:從小型範圍、簡易單元測試到複雜的廣泛測試 (單元測試與整合測試與端對端測試)。
不過,有些可能的測試類型清單很長,無法代表某種程度的複雜度,而是代表測試目標或技術。舉例來說,煙霧測試是不同的測試類別,可以是單元、端對端或其他測試,但旨在讓測試人員整體相信測試中的專案處於有效狀態。視覺測試也適用於小型元件或整個網站。
程式碼集有獨特的需求。舉例來說,在程式碼集中對齊單一功能,可能更為重要,請撰寫不同類型的測試,確保功能可正常運作。需要測試的新功能很少只有單一元件、功能或方法,對專案的影響可能會很廣,並以不同的規模分佈。
您的測試優先順序也可能取決於業務需求。高技術系統可能需要進行複雜的單元測試,才能確認獨特的演算法是否正常運作,而高度互動的工具可能應專注於視覺測試或端對端測試,以確認複雜的觸控輸入能夠產生正確的回應。
測試方式
建議您專心測試程式碼集的用途,不受規模影響。請設想使用者可能會使用專案的任何部分,這可能代表單一元件、低階函式或高階端對端用途。(如果您發現測試無法與「測試中」的程式碼完美互動,這也可以顯示任何規模的抽象化缺陷。)
請務必為每個測試案例設定明確的目標。大型「通用」測試可能會並不容易,就像在非測試程式碼中一樣。
測試導向開發的結果
測試導向開發 (TDD) 是測試規模或類型的獨特測試方法,因為這牽涉到編寫要失敗的測試,至少要先編寫要失敗的測試。這同時適用於手動和自動測試:您可描述要達成的目標、找出目前解決方案或程式碼缺少的內容,然後使用失敗測試做為解決方案。
當然,在開始建構之前,測試假設應用程式或元件中的每個可能情境,都不是很實用的做法。TDD 具有地位,當您的程式碼集變得越來越複雜時,這項功能非常實用。
TDD 也很適合用來修正錯誤。如果您可以編寫重現某個錯誤的重現情況,系統可能會將問題納入自動測試,但一開始會失敗。修正錯誤後,測試會通過,讓您無需手動確認,就能判斷修正是否成功。
不透明與清除方塊
這是指您測試系統任一部分的方式。如果這種做法不透明,您就無法看到內部內容,例如使用類別的公開介面時,而非檢查其內部。
除非有特別原因,否則最好先進行不透明箱測試,以便根據元件的使用方式設計測試,不要因為內部元件的運作方式而受到干擾。如果只仰賴程式碼路徑的「公開」介面 (不一定會向使用者顯示,但或許會公開到程式碼的其他部分),您可以重構並改善程式碼,知道測試會偵測到任何變更。
如要將「透明盒」程式碼轉換為更不透明的程式碼,其中一種方法是導入可設定的元素,例如程式碼依附元件的抽象化機制,或是用來觀察狀態的回呼,而不是該狀態與其他系統緊耦合。這樣做可以讓程式碼進一步分離,並讓您提供「測試」版本。或者,您也可以模擬程式碼與其他系統互動的位置。