哪裏摘要Cucumber步驟正確？

Question

我需要編寫一個類來強制執行有關可能會或可能不會添加到倉庫中相同容器的項目的規則，並且我希望在實現它之前將要求轉換爲Cucumber。每件商品有幾個屬性，例如「商品系列」（例如：電子產品，書籍），「商品狀態」（例如：主要庫存，缺貨庫存）和「批次」（例如：1050,1051）。

我能想到的幾個策略編寫黃瓜測試這一點，我想知道這是建議的一個：

首先，你可以列舉所有單位產品的屬性：

Given I have a tote containing: 
    | sku | client | family | status | batch | weight | 
    | 100000 | Foo  | garment | main | 1234 |  10 | 
When I add the item: 
    | sku | client | family | status | batch | weight | 
    | 200000 | Bar  | garment | main | 1234 |  10 | 
Then I should be told there is a Client conflict 

其次，你可以有一個基本的產品硬編碼，並嘗試指定最小從它不同的屬性：

Given I have a tote containing an item that's client "Foo" 
When I add an item that's client "Bar" 
Then I should be told there is a Client conflict 

這是假定DEF步驟initions包含基本屬性，並在步驟中提及屬性時覆蓋它們。

最後，你可以去抽象的另一步驟：在這裏正確的做法

Given I have a tote containing an item 
And I add an item with a different client 
Then I should be told there's a client conflict 

任何指導意見？

Answer 1

The Cucumber Book的答案將取決於您的團隊中非技術人員最易讀的內容。與QA領導和項目經理坐下來，問他們同樣的問題。我有一個類似的問題，並從第一個建議開始。然後我認定它太詳細了，跳到＃3。然後，我和項目經理坐下來，發現當我創建數據時，我不需要任何細節，但是當我們更改數據（在我們的案例中更新發票上的行項目值）時，我們希望看到那些值在步驟中。

第6章從The Cucumber Book「當黃瓜壞了」對於指導正確的細節水平確實有幫助。我真的認爲你應該給它一個閱讀，尤其是關於提出一個無處不在的語言的部分。我認爲這將幫助您決定組織的正確詳細程度。

如果您想要使用第一個測試，我的問題就是「您多久會改變一次這些值？」如果答案是「不是很」或「從不」，那麼你應該考慮他們是否增加或減損了測試的可讀性。

P.S.我仍然在閱讀The Cucumber Book，但到目前爲止，它已經非常有幫助，例如像socjopata建議的那樣指向FactoryGirl。

Answer 2

提到的第一個選項是最靈活和可重用的選項。採用第一種方法，基本上可以涵蓋您可能需要的任何情況，但也有一些缺點，您會在下面閱讀。

第二個和第三個選項更容易閱讀，這也是編寫測試時的一個重要因素。此外，似乎專注於實際測試的內容，即「Foo」和「Bar」似乎在該場景/功能中所產生的主要區別。在編寫測試時，這也是首選。

一般來說，imho寫作黃瓜測試就像把自己置於一個岩石和一個艱難的地方之間。我注意到開發人員傾向於重用和重複使用黃瓜步驟，難以理解和維護場景。 第二種方法需要更多的工作來定義步驟，但是場景更清晰且更易於閱讀......但是它需要更多時間來編寫場景以及它會產生大量的步驟定義庫，這很難維護。

If you really want Cucumber for bdd那麼我會最慷慨的第二選擇。只要確保你會使用FactoryGirl或其他類似的東西來創建通用對象，並且只覆蓋你一次需要的東西。

我希望你覺得這個很有用。