529
《Cucumber：行為驅動開發指南》——6.5 我們學到了什麼
本節書摘來自異步社區《Cucumber：行為驅動開發指南》一書中的第6章，第6.5節，作者：【英】Matt Wynne , 【挪】Aslak Hellesy著，更多章節內容可以訪問雲棲社區“異步社區”公眾號查看
6.5 我們學到了什麼
Cucumber特性對公司來說是一筆寶貴的財富。我們曾見過有團隊將他們係統中大塊大塊的部分推倒重寫，知道自己有一組準確的、可執行的規範來確保新的方案會運行得跟原來一樣好，他們自不必擔心什麼。對這些團隊來說，特性比產品代碼本身更有價值。如果你打算在編寫Cucumber特性上麵做些投入，那就要照管好這些特性，讓他們為整個團隊帶來盡可能多的益處，從而保護好這筆投入。不要遷就於緩慢的特性、間歇失敗的特性或者團隊中隻有一部分人閱讀的特性：問題一旦出現立該將其消除，讓每個問題成為一個理由，基於這些理由把測試做得比以前更好。
Cucumber看上去似乎隻是一種測試工具，但本質上它是一種協作工具。如果你真正努力去編寫特性，使它們可作為文檔提供給團隊中的非技術利益相關人，你會發現自己不得不與利益相關人討論一些原本你不會花時間討論的細節。這些討論揭示了他們對問題的深刻見解，這些見解將幫助你構建一套更好的方案。這才是Cucumber的真正奧秘：測試和文檔都隻是令人愉快的副作用而已，真正的價值在於交談過程中對於知識的發掘。
嚐試一下
下麵是一些你可以自行嚐試的練習。
在團隊中實施缺陷預防
想出使團隊生產線速度變慢的三件事情。每件事情的根源是什麼？你可以做些什麼來使它們向著好的方向變化？
關於偶然細節的練習
下麵的場景是以醜陋的命令式風格編寫的，穿插著各種偶然細節。
Scenario: Create an invoice
Given I am a signed in user with role: admin
And a client "Test Client" exists with name: "Test Client"
And a project "Test Project" exists with:
| name | "Test Project" |
| client | client "Test Client" |
And an issue "Test Issue" exists with:
| project | project "Test Project" |
| name | "Test Issue" |
And a work_unit "Test Work Unit" exists with:
| issue | issue "Test Issue" |
| completed_on | "2011-08-24" |
| hours | "7.5" |
And I am on the admin invoices page
Then I should see "Test Client"
And I follow "Test Client"
And I fill in "invoice_id" with "abc"
And I press "Submit"
Then I am on the admin invoices page
And I should not see "Test Client"
首先弄清楚來龍去脈：你認為這個係統是做什麼的？場景的用途是什麼？它在測試怎樣的行為？注意那些像蔓生雜草一般的偶然細節是如何妨礙你理清測試的實際目標的。
理解了場景的實質目標之後，基於自己的詞匯把它重寫一遍。需要的步驟應該可以少很多，但你可能會考慮使用多個場景。
用更加聲明式的風格重寫場景之後，你能找到原先場景中遺漏的一個關鍵的Then步驟嗎？
最後更新：2017-06-05 13:31:29