Jim Shore提出自動化驗收測試得不償失

　　你才剛剛步入這個炫酷、嶄新的敏捷世界。學校里的課本、那些傳統課程都已經被你拋于腦后，你游走于那些飽受歡迎、經久不衰的博客資源，說不定也從 InfoQ上吸取了一點知識和建議。此外，還有些指南告訴你：你必須讓測試自動化——尤其是面向業務的“驗收測試”，以確保需求被正確理解和滿足。哦，你猜怎么著，現在有些相同背景的專家正在提出相反的意見：千萬別把那些測試自動化了。

　　主導最近這次相反建議的討論的，是被尊為敏捷思想領袖的James Shore，夠諷刺的(不是嗎?)，他曾一度擔任Fit(Ward Cunningham的自動化驗收測試框架，該項目也開啟了自動化驗收測試的先河)項目的協調員。

　　受到與Gojko Adzic一次談話的觸動，Shore發表了他關于“(自動化)驗收測試存在的問題”的觀點，總結為以下兩點：

　　自動化測試工具的初衷，比如Fit，是想讓業務人員(“客戶”)自己寫出可執行的例子來。過去的經驗證明這非常難實現。少數情況下是由測試人員編寫的，但多數情況下是開發人員在編寫這些測試。

　　由于這些測試既慢又脆弱，還常常難于重構，它們通常會成為名副其實的維護負擔。就這一點，端到端的“集成測試”顯然事半功倍，JB Rainsberger寫了一系列的文章來闡述他這一觀點的合理性。

　　總之一句話，Shore(間接地還有Rainsberger)認為，由于不存在預期價值(客戶編寫測試)，就沒有理由投入高成本(維護)了。

　　哇，不寫自動化驗收測試?看起來真是180度大轉彎的極端想法。雖然這并不奇怪，但Brian Marick大談類似的觀點已經有一段時間了。又是一次諷刺(不是么?)，1998年Marick發表的關于自動化“面向業務測試”潛在好處的論文，成為了當時自動化驗收測試運動的先驅。然而十年后，整整兩年前，Marick卻這樣說：

　　TDD方式、白板風格、面向業務且注重實例的設計方法、可視化運作的探索性測試、以及一些少量的自動化系統整體健全性測試，程序員使用方法構建的應用軟件，開發起來將更加經濟，而且質量方面并不會比一個通過GUI做最低限度的探索性測試、以及由注重實例設計方法指導的、完全用面向業務的TDD測試所開發的應用軟件差。

　　Adzic是Shore觀點的最初接受者，他認同第一個觀點，但并不完全信服“不要自動化”的所有觀點：

　　我從未真正期望客戶自己能寫點什么，但是我在相當程度上成功說服了他們參與需求研討會，會上提出的例子隨后會被轉化成驗收測試……清晰的例子和改善的溝通是這一過程的最大好處，而使用工具也會帶來額外的收益。工具使得我們對進展有個公正的度量。Ian Cooper在對我的新書做訪談時說過“工具使開發人員保持誠實”，我很認同。用一個公正的工具來做評測，比如“完成”是真地完成了“大家一致同意的事情”，而不是“大部分都做好了剩下幾件小事明天補”。我不確定現場回顧(Shore的評論里所提到的)是否就能足以完全夠避免這些問題。

　　George Dinwiddie也認為：讓業務人員寫測試或者在這類工作中投入很多測試人員收效甚微，但他堅持認為自動化對降低回歸缺陷成本依然是很有意義的：

　　正如Elisabeth Hendrickson所說，“如果客戶有一個期望，并表達清楚了這個期望，那么他們就有充足的理由相信你已經滿足了這個期望，他們可不想非得去手動再次驗證事實上你之前就已經做好的事。”

　　要求太過分了嗎?

　　...

　　考慮到我所確信的東西還要拿去重測，而且迭代越短，他們就需要更頻繁地重測，我可不想放棄自動化測試。

　　...

　　如果我們和客戶一起著手用例開發，用客戶的話說，我們就已經完成了最難的部分。投入額外的精力讓這些用例可以運行(通過把它們自動化)從而預防缺陷是值得的，而不要在有了缺陷后再去想辦法找出它們。

　　Shore很快用一個例子繼續印證了他的觀點，那就是他和他的團隊在不使用自動化驗收測試的情況下來“消除缺陷”。在這里，Shore澄清到，他并不是建議拋棄自動化驗收測試，而是要用某些東西取代它，繼而他描述了他眼中的“某些東西”。實質上，Shore勾勒出的方法正是當下極限編程實踐的一個很棒的、嚴謹的應用(盡管如此，這篇文章還是非常值得一讀，值得收藏)。

　　在對Jim兩篇文章的回應中，Ron Jeffries參與了整個討論過程。在諸多其它觀點中，Jeffries始終像Adzic和Dinwiddie一樣，認為不該遺忘自動化：

　　Jim一直堅持說他覺得測試不自動化沒什么問題，而且即使客戶不理解也沒事。我覺得客戶不理解沒關系——盡管我傾向于客戶能理解，如果成本很低的話。測試不要自動化的理念我卻不能茍同。我擔憂的是，如果測試不能自動化，回歸就變得門戶大開、不可控制了。

　　此時，測試什么時候該自動化，什么時候不用，如果沒自動化，其它測試通常要怎樣才算做到位，就成了要關心的問題。當然，沒必要把每個用例都跑一遍來確保代碼工作正常。但可能還是要跑一些。

　　...

　　我的結論是，顯然Jim的團隊所做的事情是可行的，而且他們做的所有XP的實踐都很不錯。如果其它團隊也能將這些實踐運用得那么好，他們可能得到類似的結果。

　　而我認為：自動化那些故事的測試用例，是預防缺陷在后續故事中出現的最簡單、最有效的方法。

　　所以，每個人都重新強調了讓業務人員和開發人員一起討論用例依然是必不可少的一項。但至于自動化那些用例，Shore、Rainsberger和Marick認為也許不需要。其它人卻說需要。

　　確實是一個有趣的討論。你說呢?

原文轉自：http://www.anti-gravitydesign.com