
測試程式的結構
|
103
測試名稱不需要遵循產品程式的樣式慣例,它們實際上來自它們自己的領域特定語言。
你會很常看到較長的方法名稱與毫無節制地使用底線,就算在 C# 與 Java 等不太使用它
們的語言也是如此(有人認為
strings_can_be_capitalised
比較不需要眯著眼睛閱讀)。
測試程式的結構
確保你的測試套件涵蓋程式的重要功能。考慮“一般”的輸入情況。也考慮共通的“失
敗情況”。考慮臨界值會發生什麼事情,包括空或零狀態。使用系統與整合測試來涵蓋
整個系統的所有功能與所有需求,及使用單位測試來涵蓋所有的程式碼,都是值得稱許
的做法。但是你可能需要很認真地工作。
不要重複測試項:它會增加勞力、混亂與維護成本。每一個你所寫的測試案例都驗證一
項事實,那個事實不需要再次驗證,無論是在第二次測試,或測試其他東西的其中一部
分。如果你的第一個測試案例會在建構物件之後檢查先決條件,你就可以假設這個先決
條件在每一個你所寫的測試案例都成立—不需要在每次重新建構物件時都重新檢查。
常見的錯誤是:看到一個類別有五個方法,就認為你需要五個測試程式,每一個測試程
式負責一個方法。這是可以理解(但天真)的做法。以函式為基礎的測試經常是不實用
的,因為你通常無法獨立測試一個方法。呼叫它之後,你會需要使用其他的方法來檢視
物件的狀態。[Page-97]
相反,編寫測試程式來逐一測試程式碼的特定行為。這會產生更凝聚且更明確的測試組
合。
維護測試程式
你的測試程式碼與產品程式碼一樣重要,所以謹慎考慮它的外形與結構。如果它變混 ...