TDD/BDD會導致不完整的單元測試嗎？

Peter Ritchie最近開始擔心他認為很不妙的趨勢，即開發者為了堅持TDD與BDD 而無法寫好單元測試。特別地，他認為對“交互測試”的頂禮膜拜，最終帶來的后果是不完整的單元測試;測試無法證明某個單元(對象)能在它有可能工作的任何環境下正常工作。首先，Peter的想法中，最有趣的部分可能就是TDD與BDD之間不同核心目的的沖突。

　　Peter利用“類是真實世界概念的自然抽象”這一理念作為自己觀點的基礎。他認為良好的單元測試 應該能夠驗證這些自然抽象出來的類，但可能在未來的某個時刻開始，TDD和BDD將導致人們不去遵守這一原則：

　　我發現測試驅動開發(TDD)和行為驅動開發(BDD)這兩種方法結合在一起后存在一個問題，那就是實踐者只把系統各部分間的交互放在了最核心的位置，其實并沒有做任何“單元測試”。他們只為了追隨TDD和BDD的魔咒，最后卻只見樹木、不見森林，而成為盲目測試。單元測試的目標是獨立的單元、應用程序中最小的可測試的部分。

　　Peter引用了Wikipedia's BDD entry中的一個例子來證明他的觀點：

　　詳細的測試僅測了4,294,967,296種可能性中的13種。這些測試可能很好地測試了一個系統預期的行為，但是并沒有真正把EratosthenesPrimesCalculator當作一個單元來測試。如果系統只允許這樣的行為，那么這些測試可以證明系統是正常的。但是，如果EratosthenesPrimesCalculator超出了這13種行為而被使用的話(這也正是將代碼封裝成類的目的：重用)，那么它就算不是上已測試好的啦。

　　這個例子在很大程度上依賴于這樣一個觀點——一個單元的有效性/正確性完全是基于其名字所暗示的在現實世界中它所固有的特性。很多TDD的實踐者會向這一點發起挑戰，他們認為：一個單元的有效性只能在使用它的環境(系統)上下文中才能定義。JMock的作者之一Steve Freeman說道：

　　測試先行的交互測試的思想是理清一個對象與它的環境之間的關系。例如，你正在模擬一個DAO，但是DAO不是應用領域中一部分，它是實現領域的一部分。

　　而另一方面，很多做TDD培訓的人會不認同這一點，他們認為：先行編寫單元測試的主要作用在于它是一個單元模塊該做什么、不該做什么的顯式規約。下面文字源自于Mario Gleichmann的“TDD與按契約設計的對比”：

　　單元測試作為測試驅動開發(TDD)的一個重要組成部分，其作用并不在于能在多大程度上驗證實現的正確性，而是有助于澄清單元模塊行為的規約。事實上，驅動開發的東西應該是規約，而不是驗證。你可以在行為驅動開發(BDD)的崛起中看到這種思想的回歸。BDD其實就是要尋找一個充分的詞匯表并用一種很自然的方式編寫規約(當然，這也是可以被自動化測試的)，以便將注意力重新放到“組件在特定條件下應具有哪種行為”這個問題上來。

　　從“單元模塊是由其上下文定義的”這種觀點中引申出來的一個推論經常被引用，這個推論就是：按照單元測試的定義，它并不能反映出整體系統的質量和有效性，相反，要想做到這一點，就要在開發階段中增加各種級別的驗收測試。JS Greenwood寫道：

　　雖然集成測試少得可憐，但所有事情都被獨立測試過了——每一個組成部分都很干凈、獨立、被良好測試并且可以信任其正確性，(這也是單元測試的極限了)。但是如何保證所有組件都能協同工作呢?這是一個灰色(甚至黑色)區域，除非能充分地結合單元測試和集成測試。

原文轉自：http://www.kjueaiud.com