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