脆弱的測試案例

Sep. 23 08:40~09:42

 

Bob大叔認為好的測試案例需要符合FIRST這五個條件，也就是：

• Fast：快速執行，執行時間過久的測試案例開發人員因為不想等待所以比較不會頻繁執行它，也失去了及時回饋的目的。
• Independent：測試案例彼此之間互相獨立，不要因為測試案例的執行順序不同而產生不同的結果。
• Repeatable：測試案例可以在任何的環境中被重複執行。例如，測試案例可以在你的開發機中執行、可以在持續整合系統上執行、也可以在QA部門的測試環境中執行。
• Self-Validating：測試結果要自我驗證，不需要人為介入去判斷成功或失敗。
• Timely：Bob大叔是TDD的擁護者，他認為要在剛好在準備撰寫production code之前才開始撰寫測試案例，有種JIT（just in time）的味道，Bob大叔把這個特性稱為timely（及時）。
  

以上五點測試案例的「光明面」，有讀過《Clean Code》的鄉民應該都知道。今天Teddy要介紹的是單元測試的「黑暗面」，談一談為什麼有些測試案例很脆弱，經常會執行失敗。這個議題Martin Fowler曾經提過，Teddy也在〈對付時好時壞的測試案例(1)：還沒痊癒，就先隔離〉、〈對付時好時壞的測試案例(2)：Lack of Isolation〉、〈對付時好時壞的測試案例(3)：Asynchronous Behavior〉、〈對付時好時壞的測試案例(4)：Remote Services〉、〈對付時好時壞的測試案例(5)：Time〉）介紹過。今天介紹《xUnit Test Patterns》這本書中提到的另外四個觀點：

• Behavior Sensitivity：測試案例就是用來測試SUT（System Under Test，待測程式）的行為是否正確，如果開發人員修改了SUT的行為，則測試案例很有可能會失敗。這一點聽起來好像是廢話，但也是事實。
• Interface Sensitivity：這裡講的interface（介面）是指使用者介面，例如GUI。透過GUI來測試系統的測試案例很容易因為介面些微的改變導致測試失敗。
• Data Sensitivity：測試案例會假設在某種初始狀態中執行，這個初始狀態在測試領域中有一個術語稱為test fixture。假設在test fixture中所使用到的資料改變，例如預設資料比數異動，則測試案例就很容易失敗。
• Context Sensitivity：Context是指SUT以外的所有東西，包含DOC（depended-on component，相依物件）、外部服務、硬體設備、作業系統、系統時鐘（system clock）等。有些context具有變動性，例如系統時鐘不斷地改變，如果測試案例過分相依於系統時鐘，則很容易執行失敗。

***

看到這邊，鄉民們可以做個小練習，試看看Martin Fowler所提出以下五種造成測試案例時好時壞的因素，分別對應到上述四種狀況的哪一種？

1. Lack of Isolation（缺少隔離）
2. Asynchronous Behavior（非同步行為）
3. Remote Services（遠端服務）
4. Time（時間）
5. Resource Leaks（資源洩漏）

***

友藏內心獨白：知識的層次就是多方參考累積出來的。