939
《Cucumber：行為驅動開發指南》——第1章 為何使用Cucumber 1.1自動化驗收測試
本節書摘來自異步社區《Cucumber：行為驅動開發指南》一書中的第1章，第1.1節，作者：【英】Matt Wynne , 【挪】Aslak Hellesy著，更多章節內容可以訪問雲棲社區“異步社區”公眾號查看
第1章 為何使用Cucumber
軟件始於一個想法。
我們假設這是一個優秀的想法——一個能讓世界變得更加美好，或者至少能讓一些人賺到一些錢的想法。而軟件開發人員所麵臨的挑戰就是要落實這個想法，使其能真正產生效益。
最初的想法是完美、漂亮的。如果擁有該想法的人碰巧是一個天才軟件開發人員，那事情就非常簡單了：他無須向任何人解釋就能直接把想法實現成可工作的軟件。然而更常見的情況是，擁有最初想法的人並不具備使其想法變為現實所必需的編程技能，因此這個想法必須從他的腦中傳遞到另外一些人的腦中。也就是說，相關的人需要溝通想法。
大部分軟件項目會涉及多人緊密協作的團隊，高質量的溝通對項目的成功至關重要。你可能已經知道，高質量的溝通並不僅僅是口若懸河地把你的想法描述給他人，你還需要收集可靠的反饋以確保對方正確理解了你的意思。這就是敏捷軟件團隊要用小型增量的方式開發軟件的原因，采用增量方式開發出的軟件可用來收集反饋，詢問利益相關人：“是這個意思嗎？”
但這仍然不夠。如果開發人員誤解了一個想法，然後花了兩周的一次迭代實現了它，那麼他不僅浪費了兩周的時間，還因為引入了沒有正確反映最初想法的概念和功能而破壞了代碼的完整性。其他開發人員可能已經開始在這些錯誤想法的基礎上不經意添加了更多代碼，使它們基本上不可能完全從代碼中消失。
我們需要一種過濾器，讓我們的代碼遠離這些被誤解的想法。
1.1 自動化驗收測試
Cucumber：行為驅動開發指南
自動化驗收測試的想法源自極限編程（eXtreme Programming，XP）1，具體說就是源自測試驅動開發（Test-Driven Development，TDD）2實踐。
不是讓業務人員直接將需求交給開發團隊，然後也沒什麼反饋的機會，而是讓開發團隊和業務人員合作編寫自動化測試來表述業務人員想要的結果。我們稱之為驗收測試，因為這類測試表述了軟件需要做什麼才能讓業務人員覺得軟件可以被驗收。驗收測試寫好的時候，運行它們肯定會得到失敗的結果，因為實現代碼還不存在，但驗收測試抓住了業務人員真正關心的東西，並且讓所有人明確了完成軟件需要做哪些事情。
驗收測試和單元測試不同，單元測試針對的是開發人員，幫助他們啟動並驗證軟件設計。有一種說法是，單元測試確保你正確地編寫軟件，而驗收測試則確保你編寫正確的軟件。
自動化驗收測試作為一項既定實踐已在很多XP團隊中沿用多年，然而，許多經驗不那麼豐富的敏捷團隊似乎把TDD看作僅僅針對程序員的實踐。正如Lisa Crispin和Janet Gregory在《敏捷軟件測試：測試人員與敏捷團隊的實踐指南》一書[CG08]中指出的那樣，如果沒有麵向業務的自動化驗收測試，程序員很難知道他們需要編寫怎樣的單元測試。自動化驗收測試可以幫助團隊關注重點，確保每次迭代你所做的都是你所能做的最有價值的工作。當然你仍然會犯錯——但犯錯的概率大大降低了，這意味著你可以準點到家，享受業餘生活。
最後更新：2017-06-05 11:32:17