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