今天把《Art Of Unit Testing》的前四個章節讀完了，作者以自己的親身經歷，使用簡潔清晰的語言，為我們展現了單元測試的藝術。
1. 怎么定義一個好的測試案例呢?好的測試案例應該是在N年后還能運行良好并易于維護的。
2. TOOD - Testabled Object-Oriended Design。作者也提到了這個頗有爭議的問題，許多人認為，增加代碼的可測性的同時，會使得代碼變得更加丑陋。而作者不認為是這樣，作者認為這樣的修改 是另外一種面向對象，同樣的也是優美的，這就是TOOD。
3. 為了代碼的可測性增加的一些代碼，常常不希望編譯到最后的產品中�？梢杂泻芏噢k法，比如用宏判斷，如果使用的是.NE，還有一種辦法，就是在相應的函數或類上面使用這個Attribute：[Conditional("DEBUG")]
4. Action-Driven Testing 與 Result-Driven Testing，兩種不同的測試流派，一種檢測行為本身，一種檢查最后結果。不能說一定誰優誰劣，但作為單元測試，更多的應該是Action-Driven Testing，因為這樣可以隔離一些其他外部的不穩定因素，當你的案例失敗時，能夠更加準備的定位問題所在。(事實上，集成測試就是Result-Driven Testing，一個很大的困惑就是集成測試案例失敗了，通常是很難馬上定位到原因的。)
5. Stubs和Mocks的區別，這兩個東西看起來幾乎是一樣的，事實上也確實很相似。但是，他們的區別也同樣明顯：Stubs不會導致案例失敗，而Mocks會。換成我的理解就是，Stubs是一些假的東西，它能模擬一些我們想要的結果，而Mock呢，它就是一間諜(Test Spy)，告訴我們被測代碼做了些什么，于是，我們通過Mock對象來進行檢查。
6. One Mock Per Test，一個測試案例中，通常的模式是N個Stub對應1個Mock。如果一個測試案例有多于一個的Mock對象，說明你的案例感情不夠專一。而一個測試案例，是可以有多個Stub對象的，他們共同協作模擬一些特定的虛擬場景，然后通過Mock對象，驗證我們的被測對象是否對此做出了反應。
淘寶的接口測試白皮書
今天晚上回來后看到淘寶測試團隊發出來的《接口測試白皮書》，一口氣將它讀完，寫的還是相當不錯的，有非常多值得借鑒和學習的地方。
1. 在工作的流程上，各個測試角色是可以互補的，接口測試的設計、用例可以跟功能和性能測試共享，從而構建出整個產品各個環節的測試案例覆蓋程度。
這一點之前感觸并不深，現在看來，同一產品的不同測試團隊，像共享bug一樣，將所有人的案例都組織在一起，一起共享是一件非常值得去做的事情。
2. 我們的客戶是調用接口的人，不是開發接口的人。
說的好!之前一直以為是為開發服務，看來是上面的話總結的比較好，為調用接口的人服務。
3. 測試用例設計出來以后應該經過評審，并將評審結果以某種形式記錄下來，作為測試實施的最終方案。評審最好由以下這些人員共同參與：需求方、設計人員、開發人員、功能測試人員、接口測試人員以及這些人員的直接主管。
我們這邊的接口測試案例的設計評審還是空缺的，上周我還組織了一次功能測試人員和接口測試人員的接口測試案例評審，看來我要繼續推動這件事了。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
