今天把《Art Of Unit Testing》的前四個(gè)章節(jié)讀完了，作者以自己的親身經(jīng)歷，使用簡(jiǎn)潔清晰的語(yǔ)言，為我們展現(xiàn)了單元測(cè)試的藝術(shù)。

怎么定義一個(gè)好的測(cè)試案例呢？好的測(cè)試案例應(yīng)該是在N年后還能運(yùn)行良好并易于維護(hù)的。

TOOD - Testabled Object-Oriended Design。作者也提到了這個(gè)頗有爭(zhēng)議的問(wèn)題，許多人認(rèn)為，增加代碼的可測(cè)性的同時(shí)，會(huì)使得代碼變得更加丑陋。而作者不認(rèn)為是這樣，作者認(rèn)為這樣的修改 是另外一種面向?qū)ο?#xff0c;同樣的也是優(yōu)美的，這就是TOOD。

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

Action-Driven Testing 與 Result-Driven Testing，兩種不同的測(cè)試流派，一種檢測(cè)行為本身，一種檢查最后結(jié)果。不能說(shuō)一定誰(shuí)優(yōu)誰(shuí)劣，但作為單元測(cè)試，更多的應(yīng)該是Action-Driven Testing，因?yàn)檫@樣可以隔離一些其他外部的不穩(wěn)定因素，當(dāng)你的案例失敗時(shí)，能夠更加準(zhǔn)備的定位問(wèn)題所在。（事實(shí)上，集成測(cè)試就是Result-Driven Testing，一個(gè)很大的困惑就是集成測(cè)試案例失敗了，通常是很難馬上定位到原因的。）

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

One Mock Per Test，一個(gè)測(cè)試案例中，通常的模式是N個(gè)Stub對(duì)應(yīng)1個(gè)Mock。如果一個(gè)測(cè)試案例有多于一個(gè)的Mock對(duì)象，說(shuō)明你的案例感情不夠?qū)Ｒ弧６粋€(gè)測(cè)試案例，是可以有多個(gè)Stub對(duì)象的，他們共同協(xié)作模擬一些特定的虛擬場(chǎng)景，然后通過(guò)Mock對(duì)象，驗(yàn)證我們的被測(cè)對(duì)象是否對(duì)此做出了反應(yīng)。

如果您覺(jué)得有用，請(qǐng)您告訴我，謝謝！

總結(jié)

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

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。