測試案例壞味道（4）：Hard-to-Test Code

March 04 08:20~09:16

焗烤食物的耦合度也很高。

 

第一次看到Hard-to-Test Code（難以測試的程式碼）這個壞味道，Teddy覺得怪怪的。這應該算是測試案例的壞味道，還是production code的壞味道？根據《xUnit Test Patterns: Refactoring Test Code》書中的說明，大部份的情況的確都是因為production code的原因造成這個壞味道，但自動化測試案例本身也可能會產生這個壞味道。

導致這個壞味道的具體情況有：

• Highly Coupled Code：高耦合的程式碼通常都很難測，就好像要把打結的毛線解開一樣困難。因為待測程式與外部物件或執行環境有太高的相依性，使得準備自動化測試環境變得很麻煩、困難、耗時，有時甚至是不可能。如果耦合的對像是遠端的物件或服務，那就更難以測試了（請參考〈對付時好時壞的測試案例(4)：Remote Services〉）。
• Asynchronous Code：非同步的程式也很難測，因為不知道何時會回傳執行結果。如果等待時間太短，測試案例執行失敗但待測程式其實是正常的；反之，如果等待時間太長，則測試案例執行時間很長，導致開發人員不想頻繁執行，這樣也不好（請參考〈對付時好時壞的測試案例(3)：Asynchronous Behavior〉）。
• Untestable Test Code：測試案例本身也是程式碼，過於複雜的測試案例，可能因為包含前兩天提到的〈Obscure Test〉與〈Conditional Test Logic〉壞味道，導致測試案例本身不易被驗證。

***

簡而言之，這個壞味道告訴鄉民們兩件事。首先，production code要易於測試，也就是可測性（testability）的議題。關於這一點可以參考Teddy以前寫的文章：

• 〈如何提升軟體的可測試性（一）〉
• 〈如何提升軟體的可測試性（二）〉
• 〈如何提升軟體的可測試性（三）〉
• 〈如何提升軟體的可測試性（四）〉
• 〈Quality Attribute Scenarios（11）：Testability〉
• 〈Quality Attribute Scenarios（12）：Testability General Scenarios〉
• 〈可測性模式（上）〉
• 〈可測性模式（下）〉

其次，測試程式不要寫的太複雜，要避免像是Obscure Test與Conditional Test Logic壞味道。

***

友藏內心獨白：這個壞味道有點…壞。