昨天提到對付時好時壞的測試案例第一步就是要先將它們從main deployment pipeline隔離，把這些測試案例先暫時移到quarantined pipeline中。Martin Fowler接著舉出下列5種可能會導致測試案例時好時壞的問題，並介紹如何排除這些問題的方法。今天Teddy先介紹第一種Lack of Isolation（缺少隔離）。
- Lack of Isolation（缺少隔離）
- Asynchronous Behavior（非同步行為）
- Remote Services（遠端服務）
- Time（時間）
- Resource Leaks（資源洩漏）
造成測試案例時好時壞的第一個兇手就是測試案例彼此互相有關係，並非全然的獨立。什麼叫做彼此有關係（缺少隔離）？例如，有A、B兩個測試案例，A檢查某個物件是否被產生，B使用A所產生的物件來驗證某些狀態。在這種情況下，A跟B就不是完全獨立的測試案例。另一個常見的例子就是好幾個測試案例共用資料庫中相同一組待測資料。理論上，每個測試案例需要重建自己的測試資料，但是有時候建立測試資料很花時間，所以為了節省時間，有時會讓好幾個測試案例共用一組測試資料。但是萬一這組測試資料不小心被哪一個測試案例給改了，其他的測試案例就可能會失敗（和公用變數所造成的問題類似）。
解決這個問題的方法有兩個常見的簡單策略：setup與clean-up，前者要求測試案例在執行之前要負責把自己所需要的測試環境建好，後者要求測試案例在執行之後，必須要將測試環境恢復到執行測試案例之前的狀態。用講得太慢，請看圖。以下兩種方法，何者比較好？執行完測試案例再恢復狀態，還是每次執行之前先建立新的狀態？
這兩種做法各有各的優缺點。採用setup的方式，可以確保測試案例每次執行時都有一個已知的狀態，如果測試案例執行失敗，可能是production code有問題，或是這個測試案例本身有問題（這句不是廢話喔，等一下繼續往下看就知道）。如果是測試案例有問題，有可能是因為自己的setup步驟沒有建立起正確的測試環境，或是測試案例寫錯了。採用setup的缺點，則是因為每次執行測試案例都需要產生一個新的測試環境，所以測試案例執行速度相對來講會比較慢。
若是採用clean-up的方式，在執行一群測試案例之前，只要先把測試環境設定好一次，在執行完每一個測試案例之後，只要復原剛剛有動到的測試環境即可，不需要重新建立一次全新的測試環境。換句話說，採用clean-up的方式來執行測試案例有通常會比較快。但是，clean-up有一個非常嚴重的缺點，那就是如果測試案例執行失敗，除了可能是production code有問題，或是這個測試案例本身有問題以外，還可能是別的測試案例的clean-up有問題而導致自己出錯。如果是因為別的測試案例的問題導致自己出錯，那麼這樣的bug就不容易被找出來，請參考下圖。
換句話說，採用clean-up的方式，會導致前後緊接執行的兩個測試案例彼此有相依性，因此如果考慮到要避免產生時好時壞測試案例的機會，那麼採用setup的方式會比較好。
***
友藏內心獨白：以前經常把setup與clean-up這兩種方式混著用耶 
。
沒有留言:
張貼留言