3.1.2一個(gè)測試不是單元測試 如果 -
和數據庫交互
需要跨越網(wǎng)絡(luò )
需要訪(fǎng)問(wèn)文件系統
不能和其他的單元測試同時(shí)運行
需要配置文件才能運行
3.1.3測試驅動(dòng)開(kāi)發(fā)和驗證（verification）無(wú)關(guān)，和規范（specification）相關(guān)
測試驅動(dòng)開(kāi)發(fā)并不意味著(zhù)單元測試驅動(dòng)的開(kāi)發(fā)。實(shí)際上，測試驅動(dòng)開(kāi)發(fā)這個(gè)詞非常容易引起誤解。在TDD的大佬們眼中，單元測試只是測試驅動(dòng)開(kāi)發(fā)的工具，而不是目的。測試驅動(dòng)開(kāi)發(fā)更關(guān)注這個(gè)代碼單元應該如何運行（behave）而不是這個(gè)代碼單元實(shí)現是否正確（verification）。之所以叫測試驅動(dòng)開(kāi)發(fā)，意義及在于此。最近你可以看到一個(gè)新名字的興起-行為驅動(dòng)開(kāi)發(fā)（Behaviour Driven Developemnt）。BDD更強調一個(gè)組件應該如何工作，以及尋找一個(gè)簡(jiǎn)易的方法來(lái)規范行為。
3.1.4為什么需要單元測試？
可以單獨地測試每個(gè)單元
可以用于驗證重構后的代碼
可以用來(lái)確保不會(huì )破壞其他人的代碼
可以用來(lái)提高系統設計，比如說(shuō)，不能單元測試的代碼將不會(huì )出現
3.2 對怎么樣的代碼做（不做）單元測試？
參考http://blog.stevensanderson.com/2009/11/04/selective-unit-testing-costs-and-benefits/
【摘要】該文作者在總結3年的TDD實(shí)踐經(jīng)驗的時(shí)候，反復認識一個(gè)情況：對于某些類(lèi)型的代碼，單元測試工作得很好，也極大的提高了待測代碼的質(zhì)量；但對另外一些類(lèi)型的代碼，單元測試耗費了大量的時(shí)間，并沒(méi)有起到輔助設計和減少缺陷的作用，同時(shí)還導致代碼更加難以維護。
基于這個(gè)想法，作者畫(huà)了一張圖來(lái)表示：
作者認為，
（1）代碼本身很復雜但是對外部的依賴(lài)很少（左上），最適合單元測試，因為耗費較少和收益較多。一般來(lái)說(shuō)，某種算法（排序），核心業(yè)務(wù)規則，數據解析類(lèi)似的模塊屬于這樣的代碼
（2）帶有很多依賴(lài)的瑣碎代碼（Trivial Code with many dependencies，右下）：稱(chēng)為協(xié)調者（Coordinators），因為這些代碼主要用于集成多個(gè)代碼單元和安排代碼單元之間的交互。這些代碼不適用于單元測試，因為耗費很高，收益卻不大。
（3）代碼很復雜而且外部依賴(lài)很多（右上）：過(guò)于復雜的代碼，需要重構。
（4）外部依賴(lài)較少的瑣碎代碼（左下）：這些代碼可測可不測，因為重要性不高，復雜度也不高，加單元測試的意義不是很大。
對于作者的這個(gè)想法，我比較同意。正如我在2.2.4和2.2.5中提到的，對于一個(gè)在線(xiàn)系統（web-based application）來(lái)說(shuō)，可以分為內外兩個(gè)圈：內圈由核心領(lǐng)域對象（Core Domain Object）構成，外圈由大量鏈接匯編代碼構成。所謂核心領(lǐng)域對象，這些對象包含核心業(yè)務(wù)邏輯，數目相對較少，邏輯相對比較復雜，接口（API）相對比較穩定，輸入輸出相對比較清晰，屬于算法類(lèi)代碼，最合適單元測試，也需要單元測試來(lái)提高相應的質(zhì)量。同時(shí)我想強調一下：這些對象一定要精心設計，精挑細選，一定要滿(mǎn)足數量少，接口穩定，輸入輸出清晰這三個(gè)要求。數量少意味著(zhù)需要測的代碼少，相應的單元測試數量也少。接口穩定意味著(zhù)用戶(hù)界面的變化（或需求變化）對單元測試的影響較小。輸入輸出清晰意味著(zhù)容易驗證邏輯的正確性。相對的，外圈的代碼主要用來(lái)鏈接多個(gè)領(lǐng)域對象，安排他們之間的交互，轉換成用戶(hù)界面需要的數據結構。也就意味著(zhù)外圈代碼和需求緊密相連，微小的用戶(hù)界面變化將會(huì )導致相應的代碼代碼，寫(xiě)單元測試得不償失。
3.3單元測試最佳實(shí)踐和測試驅動(dòng)開(kāi)發(fā)反模式
參考http://blog.stevensanderson.com/2009/08/24/writing-great-unit-tests-best-and-worst-practises/
（1）單元測試之間應該完全獨立的
不要寫(xiě)不必要的斷言，每次只測一個(gè)代碼單元，模擬（Mock）外部依賴(lài)，避免不必要的前提條件。
（2）單元測試應該運行得很快（比如說(shuō)少于5 min）
單元測試需要運行得很快，這樣程序員才愿意經(jīng)常運行單元測試。這就意味著(zhù)（1）單元測試不要訪(fǎng)問(wèn)數據庫（2）單元測試不要訪(fǎng)問(wèn)網(wǎng)絡(luò )（3）外部依賴(lài)需要被模擬（mock）
（3）給單元測試一個(gè)清晰和一致的命名
一個(gè)單元測試的名字應該包含3項內容：待測對象_待測案例_期望結果，比如說(shuō)ProductPurchaseAction_IfStockIsZero_RendersOutOfStockView()。
（4）常見(jiàn)的TDD反模式
撒謊者：所有測試案例都通過(guò)了，看上去是有效的。但如果靠近看，你會(huì )發(fā)現這些案例完全沒(méi)有測試預期的內容
過(guò)度配置：一個(gè)單元測試需要一堆配置然后才能開(kāi)始測試。有的時(shí)候需要幾百行代碼配置環(huán)境，設計數十個(gè)對象。
巨人：一個(gè)單元測試需要測試數千行代碼，并且包含大量的測試用例。
無(wú)用者 ：有的時(shí)候模擬是有效的方便的。但是其他一些時(shí)候，過(guò)多的模擬對象，Stub對象，假對象，導致單元測試主要在測模擬對象而不是實(shí)際的系統。
檢察官：?jiǎn)卧獪y試對待測代碼非常了解，任何對待測代碼的變化將影響單元測試代碼。
慷慨的富有者：多個(gè)單元測試共享測試數據，任何一個(gè)單元測試改動(dòng)了一些數據，其他的測試全部失敗了。
本地英雄：?jiǎn)卧獪y試依賴(lài)于開(kāi)發(fā)環(huán)境某些特定的配置。這意味著(zhù)：在其他環(huán)境上運行單元測試將會(huì )失敗。
采集者：?jiǎn)卧獪y試驗證所有的輸出盡管它只對某些數據感興趣。
狗仔隊：?jiǎn)卧獪y試依賴(lài)于特定的實(shí)現細節，比如說(shuō)，單元測試捕獲待測代碼中拋出的每一個(gè)異常。
欺瞞者：?jiǎn)卧獪y試驗證了一大堆無(wú)關(guān)的細節，但從不測試核心行為。比如說(shuō)，待測代碼訪(fǎng)問(wèn)數據庫并返回數據，單元測試驗證每個(gè)返回的數據。
大聲說(shuō)話(huà)的人：?jiǎn)卧獪y試輸出一大堆診斷信息，日志信息，然而沒(méi)有清晰的成功/失敗標志。
please refer tohttp://tdd-antipatterns.net/index.php?title=Main_Page
4. 結論（前途在哪里）
現在，我想答案應該比較清楚了。
第一，重新強調單元測試和測試驅動(dòng)開(kāi)發(fā)的目地：通過(guò)寫(xiě)單元測試來(lái)澄清接口（幫助系統設計），確保核心代碼（i.e.Domain Object）的正確性。它不是一個(gè)檢測缺陷的有效工具，也不應該只用覆蓋率來(lái)衡量單元測試的質(zhì)量
第二，只對核心代碼（比如說(shuō)主要業(yè)務(wù)對象）進(jìn)行單元測試。待測對象需要有相對有限的API數量，比較穩定的接口定義和清晰的輸入輸出。不要把寶貴的時(shí)間花在測試大量的非核心代碼，比如說(shuō)，鏈接（多個(gè)核心對象），協(xié)調（多個(gè)核心對象），和需求/用戶(hù)接口緊密相關(guān)的代碼。
第三，不要濫用單元測試，請時(shí)刻關(guān)注最佳實(shí)踐和TDD反模式。
第四，好的單元測試來(lái)源于好的設計。設計不好，代碼不會(huì )好，單元測試也不會(huì )好。
最后，我還想繼續研究行為驅動(dòng)開(kāi)發(fā)（BDD），看看BDD是否更實(shí)用，請繼續關(guān)注。
文章來(lái)源于領(lǐng)測軟件測試網(wǎng) http://kjueaiud.com/
