TDD的另一個問題或弱點是：總有許多TDD的壞例子。許多提倡TDD的網(wǎng)站都提供了樣例代碼，基本是像這樣的：你有一個需要測試新類的單元測試。單元測試通常對要測試的類設(shè)置一個屬性并試著復述這個屬性。有了合理大小的任何類，可以快速漂亮地對單元測試進行設(shè)置。但是，我們稍微往后退點，我們究竟在測試什么？好吧，我們在測試代碼是否能夠接受一個值以及檢索該值的可能性的場景中，一切都是平等的。這歸結(jié)起來是測試編譯器或翻譯器，因為作為一名開發(fā)人員，你所寫的實現(xiàn)這個行為的代碼的數(shù)量（以及其復雜度）接近零。換句話說，這樣的測試只提供一個虛假的安全感，因為到后你什么也沒測到。反對其的理由是：隨著時間的推移，這種getter/setter代碼或許會變得更復雜，接著單元測試代碼變得能幫助避免回歸。但是我們的經(jīng)驗表明，a）當規(guī)模大得能使起初的努力變得有價值時幾乎不會出現(xiàn)這種情況了；b）如果你在對你的代碼做如此大的改變，從基本的getter/setter配對變?yōu)楦鼜碗s的計算，那么很可能你希望你的單元測試中斷。對于單元測試來說，這個故事的寓意是什么呢？我們要完全放棄他們嗎？不，但是我們認為這需要考慮對于單元測試你真正想要的是什么。的單元測試覆蓋對我們來說意味著我們在浪費精力。換個角度，TDD作為一個概念并不壞，感覺它迫使你思考你真正需要建立什么以及你怎么讓它被接受（測試它）。但是我們認為它的基本方法給了開發(fā)人員太多“權(quán)力”。給人的大印象是：開發(fā)人員（在時間壓力下）試圖創(chuàng)建通過測試的“東西”，這樣而已。因此，如果測試錯了，那么并不是開發(fā)人員的錯。我們覺得它低估了一名的開發(fā)人員的實力并給了任何有代碼編譯器的人一個定義自己為開發(fā)員的機會。這是不對的。
　　尋找軟件可測試性，我們發(fā)現(xiàn)了另一個我們不可能接受的問題——生成“可測軟件”的方法放在你的架構(gòu)上的壓力。讓一個系統(tǒng)“可測”是一件事，但依我們之見，對架構(gòu)實施嚴格原則（反轉(zhuǎn)控制，依賴注入或極其嚴格的層分離）只會大大降低代碼的難度；還有很重要的一點：它對系統(tǒng)的目標（即解決問題）沒有幫助。對于高難度的系統(tǒng)，這樣的方法或許是可防御的，甚至是非常好的。但是在這個我們居住的快節(jié)奏不斷變化的世界里，我們諸多問題中小的一個是：如果我們已經(jīng)知道兩年的時間整個業(yè)務(wù)系統(tǒng)都將被廢棄，那一個軟件是否能維持十年。我們甚至會認為兩年的時間關(guān)于一個好架構(gòu)該是什么樣的見解將會大大地改變。那么還這么麻煩干嘛？我們應(yīng)該集中精力到有用的(好是在前所未有的短時間內(nèi)上市的)軟件上。
　　因此我們的結(jié)論是：應(yīng)該抱著懷疑的態(tài)度來看待任何需要額外重新策劃基本可行可靠的架構(gòu)的測試方法。因此，我們不使用要求我們的代碼能夠在沒有數(shù)據(jù)庫的情況下工作的單元測試。我們不使用復雜的“mocking”，我們不花時間使我們的類和對象彼此獨立。我們知道這并不會生成“正確的”代碼。但是，我們并不介意。如果明天我們找到一個更好的方法，我們將改變我們的代碼模板且只需重新生成我們的app代碼。所以我們對首先創(chuàng)建正確的架構(gòu)并沒有過度擔心——事實上我們已經(jīng)改了它兩次了，但是那是另一個blog。
　　那么這是不是意味著測試驅(qū)動開發(fā)的結(jié)束？完全不是。也有你可以用單元測試測試地很好的東西。另外，還有一個新的我們已調(diào)查過的衍生，它表明了我們想測試其他領(lǐng)域：行為驅(qū)動開發(fā)（BDD）的承諾。BDD有著和TDD一樣的開端，某種意義上講，開發(fā)流程的開始是對（將來的app會需要通過以被接受的）測試的定義。但是BDD更適合這個任務(wù)，因為似乎比起它該如何被創(chuàng)建，它更注重一個系統(tǒng)的功能。因此，對TDD很少有什么不好的評價。一方面，它通過使用特定語言指定測試（或驗收標準，如果你愿意的話）提供了一個連接用戶和開發(fā)人員的方法。這種語言，Gherkin(github.com/cucumber/cucumber/wiki/Gherkin)，是如此簡單以至學習曲線相當平緩，表明每個人都可以在前所未有短的時間內(nèi)學習理解它。寫正確的Gherkin需要更多時間。對我們來說，其主要優(yōu)勢是Gherkin提供一個方法讓開發(fā)人員可以在可理解的水平上交流一個系統(tǒng)的功能。其主要缺點是你終要用許多Gherkin完整地描述一個系統(tǒng)的合理大小。
　　后，這是我們關(guān)于大多數(shù)這些“方法”（包括UML在內(nèi)）的主要評論。如果你有一個不僅僅是一個簡單的計算器的系統(tǒng)，那沒有足夠強大的建模語言可以以這樣一種你可以理解并比看著屏幕和實現(xiàn)這些屏幕的代碼更快地描述它的方式來描述一個全面完整的系統(tǒng)。
　　所以，調(diào)查繼續(xù)……
版權(quán)聲明：本文出自 SPASVO澤眾軟件測試網(wǎng)：http://zxzscq.com/news/html/2015430104822.html
原創(chuàng)作品，轉(zhuǎn)載時請務(wù)必以超鏈接形式標明本文原始出處、作者信息和本聲明，否則將追究法律責任。