正如Kevin Smith最近所稱，行為驅動開發（BDD）可以用來增進業務相關人員和軟件開發者之間的溝通，然而在使用Cucumber運行自動化測試時，有一些常見的反模式需要避免。Aslak Helles y（Cucumber聯合創建者）、Matt Wynne和Steve Tooke在最近的一次討論中對其進行了描述。
許多Cucumber的反模式涉及場景（scenario），也就是一段在特征細節層面對業務行為的描述。一個場景通常應該使用領域語言來描述具體業務行為。具體結構是由一個初始條件開始，緊隨一個觸發場景的事件，最后通過一個或一些語句來表示所期望的結果。Given-When-Then結構是一種通用的模板，如：
場景：從賬戶成功取錢
Given：我賬戶有€100
When：我申請取€20
Then：€20被取出
在寫完代碼之后寫場景，這是把Cucumber當作測試工具來使用，雖然確實有這個作用，但Cucumber首先是一個用來查看你對問題領域理解程度的工具，從而在寫代碼前能與問題領域的專業人士一起找出潛在的誤解。
由領域內專家獨立創建場景，這不能代表普通的認知，也缺少了開發和測試人員的參與。沒有技術人員的參與，場景也將很難達到自動化。
通過UI測試也會產生問題。用戶接口（UI）往往比業務邏輯變化更頻繁，從而導致測試案例經常失敗。如果并沒有改變場景或業務邏輯，那么重新調試這些失敗的測試案例，花費的就是不必要的精力。另一方面，通過與應用的各部分交互，再進入數據存儲及后端來進行測試的速度也很慢。這樣測試也可能導致缺乏對領域的理解。描述UI使用的主要是各領域通用的一般語言，這會導致場景的描述不能真實反映該領域所需要表達的情況。
瑞典資深BDD專家Thomas Sundberg引用敏捷測試金字塔并主張BDD應該被應用于所有業務有理由對具體行為產生異議的地方。他傾向于著重在集成測試上使用BDD，并盡可能少地通過UI進行測試。他同時強調Cucumber主要不是一個測試工具，而是一個用于對系統工作方式產生共同理解的工具。
保留噪音場景，如查看空銀行賬戶，這會使文檔的相關部分模糊不清。雖然噪音場景的邏輯是理所當然的，但還需要在第一次運行測試時將它們覆蓋到。Helles y他們的建議是一段時間后刪除它們，或至少改述成更有用的場景。
過度使用場景提綱會使測試變慢。有了場景提綱，可以使用模板添加新場景，這能很方便地增加大量場景。建議使用場景提綱時避免通過UI或其他較慢的方式進行測試。
其他論及的反模式包括同時測試許多規則以及糟糕的場景命名，這些都會導致誤解場景的目的。附帶的細節和過于模糊的場景，它們沒有實際的價值，要么引入了過多無關細節，要么過于抽象根本沒有包含任何細節。
查看英文原文：Behaviour-Driven Development Anti-Patterns
京公網安備 11010502049343號