小黃瓜情況應該總是有步驟嗎？

Question

當小黃瓜定義場景有時有鑑於和當步驟之間沒有明顯的區別，即，存在與從用戶和驗證的目的，系統中沒有活性相互作用，以驗證系統應該如何看在某些情況下。

考慮以下幾點：

Scenario: Show current balance 
Given user is on account page 
Then user should see his balance 

VS

Scenario: Show current balance 
When user goes to account page 
Then user should see his balance 

我不知道我會一直使用第二個變種。如果我有多個場景共享上下文「用戶在帳戶頁面上」，其中一些用戶有其他用戶操作，而另一些則沒有用戶操作，那麼在我看來，將「用戶帳戶頁面」保留爲給定步驟應該是有效的即使它在某些情況下可能缺少「何時」。這是一種有效的方法嗎？

Answer 1

形式上和技術上黃瓜/ SpecFlow不需要你寫一個當步或者更確切地說，鑑於/時/然後在命令剛執行的都寫在方案中。在這方面你不需要一個時間步驟。

但是，正如安迪·懷特寫了一下，當步上顯示的動作或事件，您的系統從「設置」才能到達您在隨後步驗證新的狀態。在這方面，每個測試都應該存在一個時間步驟（正如你所寫的：我們測試的是什麼）。

這使得你最後的評論;那麼如何驗證設置（假定系統已啓動，那麼數據庫就像一個天真的例子一樣乾淨）。在這種情況下，可以跳過When-step。

所以，一如既往地把它歸結爲可讀性和理解。編寫場景是爲了使我們對系統行爲的思考具體而清晰。使用優化的形式來理解和學習有關的行爲。

想都沒想太難這個我可能會想，一般的建議是始終使用時步，使事件或行爲非常明顯和清晰。在可能的情況下，我會避開隱含和隱藏的行爲。

我希望這會有所幫助。

Answer 2

一般的場景由3個部分組成：

• 設置（指定）
• 動作（當）
• 驗證（當時）

有時設置ISN」 t要求（或者是隱含的）。但我想不出任何你不需要採取行動和核實的情況。

Answer 3

安迪+馬庫斯同意在這裏，但我有一些意見，可能是有用的。

1. 小黃瓜特徵文件應作爲系統行爲的活文檔。 由於這個原因，場景應該提供足夠的細節來向開發人員和其他項目利益相關者（產品所有者，測試人員等）傳達體現該功能的業務規則。

   我認爲你的問題可能是由於在闡述場景時不考慮這個業務規則的端到端而產生的。我不得不問一個問題，什麼是平衡？因此，我覺得你可能需要一個步驟來至少傳達這個概念 - 在用戶看到他們的平衡之前，他們必須有一個。

   Scenario: Show current balance 
       Given I have a balance 
       When I go to my account page 
       Then I should see my balance 
   

2. 設置系統狀態（即任何「給定」步驟），讓您可以清楚地測試系統是否正常工作是非常重要的 - 否則你怎麼確定的平衡實際上是正確的嗎？你可能希望使這更明確通過指定一些參數：

   Scenario: Show current balance 
       Given my balance is £10 
       When I go to my account page 
       Then I should see my balance as £10 
   

3. 我不知道你正在使用的BDD框架，但我用貝哈特它允許你映射多個小黃瓜一步一個步驟定義。即

   user is on account page 
   user goes to account page 
   

   既可以映射到該導航用戶的頁面的步驟的定義。系統行爲是相同的，區分這兩者的唯一理由就是讓您的場景更具可讀性。

Answer 4

我的理解是，當你寫一個場景時，需要3個步驟。

1. 您的應用程序應該在開始的狀態。
2. 用戶必須做些什麼來達到某個狀態。
3. 用戶行爲的結果/輸入，即您的方案的結束點。

因此，方案將是這樣的：

Given the user is on the profile page 
When the user goes to the balance page 
Then the user should see their balance 

的個人資料頁面將是用戶可以點擊一個按鈕或鏈接接取他們的平衡。

然後有一個背景：

Given the user is logged in 
And the user has a balance