今天把《Art Of Unit Testing》的前四個章節讀完了，作者以自己的親身經歷，使用簡潔清晰的語言，為我們展現了單元測試的藝術。

怎么定義一個好的測試案例呢？好的測試案例應該是在N年后還能運行良好并易于維護的。

TOOD - Testabled Object-Oriended Design。作者也提到了這個頗有爭議的問題，許多人認為，增加代碼的可測性的同時，會使得代碼變得更加丑陋。而作者不認為是這樣，作者認為這樣的修改 是另外一種面向對象，同樣的也是優美的，這就是TOOD。

為了代碼的可測性增加的一些代碼，常常不希望編譯到最后的產品中。可以有很多辦法，比如用宏判斷，如果使用的是.NE，還有一種辦法，就是在相應的函數或類上面使用這個Attribute：[Conditional("DEBUG")]

Action-Driven Testing 與 Result-Driven Testing，兩種不同的測試流派，一種檢測行為本身，一種檢查最后結果。不能說一定誰優誰劣，但作為單元測試，更多的應該是Action-Driven Testing，因為這樣可以隔離一些其他外部的不穩定因素，當你的案例失敗時，能夠更加準備的定位問題所在。（事實上，集成測試就是Result-Driven Testing，一個很大的困惑就是集成測試案例失敗了，通常是很難馬上定位到原因的。）

Stubs和Mocks的區別，這兩個東西看起來幾乎是一樣的，事實上也確實很相似。但是，他們的區別也同樣明顯：Stubs不會導致案例失敗，而Mocks會。換成我的理解就是，Stubs是一些假的東西，它能模擬一些我們想要的結果，而Mock呢，它就是一間諜(Test Spy)，告訴我們被測代碼做了些什么，于是，我們通過Mock對象來進行檢查。

One Mock Per Test，一個測試案例中，通常的模式是N個Stub對應1個Mock。如果一個測試案例有多于一個的Mock對象，說明你的案例感情不夠專一。而一個測試案例，是可以有多個Stub對象的，他們共同協作模擬一些特定的虛擬場景，然后通過Mock對象，驗證我們的被測對象是否對此做出了反應。

如果您覺得有用，請您告訴我，謝謝！

總結

以上是生活随笔為你收集整理的我的测试生活感悟2 - Art Of Unit Testing的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。