《Cucumber：行為驅動開發指南》——6.5 我們學到了什麼

本節書摘來自異步社群《cucumber：行為驅動開發指南》一書中的第6章，第6.5節，作者：【英】matt wynne , 【挪】aslak hellesy著，更多章節内容可以通路雲栖社群“異步社群”公衆号檢視

cucumber特性對公司來說是一筆寶貴的财富。我們曾見過有團隊将他們系統中大塊大塊的部分推倒重寫，知道自己有一組準确的、可執行的規範來確定新的方案會運作得跟原來一樣好，他們自不必擔心什麼。對這些團隊來說，特性比産品代碼本身更有價值。如果你打算在編寫cucumber特性上面做些投入，那就要照管好這些特性，讓他們為整個團隊帶來盡可能多的益處，進而保護好這筆投入。不要遷就于緩慢的特性、間歇失敗的特性或者團隊中隻有一部分人閱讀的特性：問題一旦出現立該将其消除，讓每個問題成為一個理由，基于這些理由把測試做得比以前更好。

cucumber看上去似乎隻是一種測試工具，但本質上它是一種協作工具。如果你真正努力去編寫特性，使它們可作為文檔提供給團隊中的非技術利益相關人，你會發現自己不得不與利益相關人讨論一些原本你不會花時間讨論的細節。這些讨論揭示了他們對問題的深刻見解，這些見解将幫助你建構一套更好的方案。這才是cucumber的真正奧秘：測試和文檔都隻是令人愉快的副作用而已，真正的價值在于交談過程中對于知識的發掘。

嘗試一下

下面是一些你可以自行嘗試的練習。

在團隊中實施缺陷預防

想出使團隊生産線速度變慢的三件事情。每件事情的根源是什麼？你可以做些什麼來使它們向着好的方向變化？

關于偶然細節的練習

下面的場景是以醜陋的指令式風格編寫的，穿插着各種偶然細節。

首先弄清楚來龍去脈：你認為這個系統是做什麼的？場景的用途是什麼？它在測試怎樣的行為？注意那些像蔓生雜草一般的偶然細節是如何妨礙你理清測試的實際目标的。

了解了場景的實質目标之後，基于自己的詞彙把它重寫一遍。需要的步驟應該可以少很多，但你可能會考慮使用多個場景。

用更加聲明式的風格重寫場景之後，你能找到原先場景中遺漏的一個關鍵的then步驟嗎？