測試案例壞味道（6）：Test Logic in Production

March 04 11:25~12:24

測試中…XD。

 

如果production code含有測試邏輯，這樣的程式就具備Test Logic in Production壞味道。等一下…有多年開發經驗的鄉民可能會說：「不是有人說過，每個class應該帶有驗證自己正確性的測試案例（一個main程式）？」怎麼這種做法現在變成壞味道了？在xUnit工具尚未流行之前，的確是有人建議每一個class應該自行攜帶自我驗證的測試案例，Teddy也見過有人這麼做，而且還做得不錯（跑一隻main程式就把class的所有function測試完畢）。不過，有了單元測試工具之後，「橋歸橋，路歸路」，還是把production code和test code分開來比較好。

《xUnit Test Patterns: Refactoring Test Code》書中提到導致這個壞味道的具體情況有：

• Test Hook：在待測程式中用條件式來區分在production環境與測試模式所執行的程式碼。

if (isTestMode) { …..  }

else {  ….. }

這種程式Teddy以前也寫過，因為production code與特定硬體相關，在一般的測試環境並沒有這樣的硬體。為了讓測試案例通過，所以在production code中用條件來區分。Test Hook不但是壞味道，也是一種增加可測性的模式（請參考〈可測性模式（下）〉），不過能避免還是儘量避免，以免汙染production code也容易造成不預期的行為。

• For Tests Only：為了存取物件內部資料，有時候會在物件身上設計只有測試案例會使用的函數或是資料成員。這些「僅供測試使用」的程式碼，讓物件的介面變的複雜，不但可能誤導其他客戶端程式，也容易降低production code的可讀性。
• Test Dependency in Production：理論上production code不應該參考任何test code或是測試環境所使用的元件，但有時候開發人員可能不小心在production code中參考到測試專案的物件或是元件。程式在測試環境中可以正常執行，一但佈署到production環境中卻無法執行。
•  Equality Pollution：在比對測試結果的時候，有時候需要比對兩個物件的內容是否相等。為了執行物件相等的比對，有些測試工具要求開發人員覆寫equals函數。這種為了測試比對的目的所提供（覆寫）的equals函數，對production code並不需要，因此也算是Test Logic in Production壞味道。如果遇到這種情況，可以考慮在測試案例中提供客製化比對函數來避免汙染production code。

***

Separation of concern（關注點分離）是軟體設計的一個基本原則，套用此原則，還是儘可能將production code與test code分乾淨比較好。

***

友藏內心獨白：怎麼有人又是pattern有是bad smell啊！