不健康的測試行為(Behavior Smells)
1. Assertion Roulette
在一個測試的函式中, 有很多assertion失敗, 你會搞不清楚到底是哪一個有問題, 或是真正的原因是甚麼.
這通常代表這個測試的函式, 一次想要測試很多功能, 所以導致失敗時會顯示多個assertion都不過. 可以適當地, 讓每個測試函式一次測試一個功能, 讓錯誤發生只會有一個 assertion 出現.
當然有時候可能是都沒有適當的 assertion 出現, 所以可能要依靠 debugger 找出問題所在.
2. Erratic Test
有時候測試會成功, 有時候測試會失敗.
這可能分成以下幾種狀況:
(1) Interacting tests: 某些測試會跟另外的測試有關, 通常因為有共用的fixture.
(2) Interacting Test Suites: 有些測試在他自己的suite會執行成功, 但是跟其他suite合在一起執行便會失敗.
(3) Lonely Tests: 某個測試在suite內執行會成功, 但是自己單獨執行會失敗
A test can be run as part of a suite but cannot be run by itself
(4) Resource Leakage: 測試程式或是受測程式會消耗光系統的資源
(5) Resource Optimism: 測試指在某個環境下會通過, 換到另一個環境會失敗
(6) Unrepeatable Test: 第一次執行會成功, 之後再執行會失敗
(7) Test Run War: 當有很多人通時執行測試時, 會導致測試會隨機失敗
(8) Nondeterministic Test: 即使只有一個人在執行測試, 都會導致測試會隨機失敗
3. Fragile Test
當受測程式有些修改時, 會導致測試程式失敗.
這可能分成以下幾種狀況:
(1) Interface sensitivity: 因為受測程式的部分介面有修改, 導致測試編譯失敗或是執行失敗
(2) Behavior sensitivity: 因為有加新功能到受測程式, 或是有修改bug, 導致本來成功的測試失敗
(3) Data sensitivity: 因為用來測試受測程式的資料有變, 導致測試失敗
(4) Context sensitivity: 因為受測程式的執行環境有些改變, 導致測試失敗
(5) Sensitive Equality: 要比對的字串, 因大小寫有變, 導致測試失敗
(6) Fragile Fixture: 為了新的測試來修改原來的fixture, 導致其他的測試失敗
4. Frequent Debugging
當測試失敗時, 需要要求手動介入除錯
這是因為:(1) 缺法 defect localization 的機制, (2) 缺乏較詳細的單元測試, 來驗證內部邏輯或是單一的 class, (3) 缺乏針對一堆class 的 component class, 來確認類別間的整合問題.
留言列表
