BDD故事的驗收標準（和其他內容）

Question

我們有一個工作流引擎，提供可用工作流的列表（我的意思是工作流定義，而不是實例），用戶可以單擊任何工作流旁邊的「Execute」鏈接，好吧，執行該工作流程的一個新實例。我想以BDD的方式執行「執行工作流」故事（功能？）。

Story: execute a workflow 
    Scenario: execute a workflow by clicking on execute link in workflow list and nothing goes wrong 
    Given I am a user with sufficient rights 
    And I have added a workflow called "wf" 
    When I click on the execute link next to "wf" in the workflows list 
    When I view the list of workflow executions 
    Then the output is: 
""" 
    1 | wf1 | not started 
""" 

（第1列：編號，第二：工作流名，第3：狀態）

我有點兒覺得這更像是一個爛攤子比一個漂亮的切DBB情況下，我特別關心驗收標準。我的思路並不清楚我應該如何處理像「執行工作流程」這樣粗糙和用戶耦合的東西。我的意思是，當你在做API的時候，一切都很清楚，但是如果你描述的是通過（人類）用戶交互發起的一些行爲，並且結果通過啓動另一個具有複雜輸出的用例就很明顯（如列表項目）。知道工作流確實執行的標準是在工作流執行列表中看到一個新項目，這是另一個故事。我有點困惑。

我應該與數據庫層交談並檢查是否存儲新創建的工作流實例的行 - 或者 - 我應該檢查是否存在指向工作流執行列表中的新實例的項目？如果第二，那究竟如何？我應該在一種情況下檢查所有具有正確值的列嗎？還是在它自己的情況下檢查每列？

Answer 1

我可以向你推薦我最近在Acceptance Criteria vs. Scenarios上做過的文章嗎？我認爲，如果您使用類似於工作流引擎特定用途的東西，而不是通用的東西，那麼示例可能更具啓發性。例如，here's a fake pet shop我正在使用它來嘗試一個自動化工具。我已經written scenarios around the pet shop，而不是試圖指定一般的自動化問題。

例如，如果您的客戶有時在醫療保健領域，例如，敲一個假的診斷工具，使用您的引擎，並寫下一個場景。一開始可能看起來有點工作，但我發現它很快就會收回成本。

Story: A doctor diagnoses black death 

Scenario: The doctor starts the diagnosis 

Given I am doctor with rights to use the system 
And I've added a workflow called "diagnosis" 
When I choose the "diagnosis" workflow 
Then it should tell me that it's not started. 

這是您正在尋找的好處 - 用戶獲取一些信息，而不是某些東西存儲在數據庫中。儘可能地，一個場景應該推動最終價值！因此，也許它甚至應該說是這樣的：

Story: A doctor diagnoses Black Death 

Scenario: The doctor starts the diagnosis 

Given I am doctor with rights to use the system 
And I want to diagnose a patient 
When I choose "Diagnosis" 
Then the system should prompt me to start diagnosing. 
Given that all the symptoms match Black Death 
When I perform the diagnosis 
Then I should be able to diagnose the patient with Black Death. 

這是爲了使用方便和審美需要的任何小的步驟是真正的可用性問題。不要使用BDD框架來描述可用性問題（儘管它們可以通過它們，從而爲您提供迴歸測試）。相反，請手動嘗試。 BDD不是手動測試的替代品，它只是有所幫助。

如果您可以創建一個模糊的現實使用的工作流引擎，它會幫助您考慮您可能會錯過的場景。例如，我現在不知道該工作流程如何與特定患者相關聯。我發現具體的，富有想象力的例子往往會幫助人們將其他場景視覺化，而不是模糊，通用和包羅萬象的東西。

此外，請嘗試用企業可能使用的相同語言進行表述，思考您真正想要的業務成果。儘量不要去考慮如何實現這個場景 - 而是寫下來。這將是更容易，更容易如果你真的去和商業人士或客戶談談他們能想到的情景！

使場景運行所需的任何複雜性都會進入代碼，在這裏代碼更容易維護和重構。

作爲一個額外的好處，通過識別特定客戶的特殊需求，您可以幫助您的客戶避免將所有可能的功能放入工作流引擎以防萬一需要。通過與真實人物交流真實場景，他們將能夠幫助確定哪些人最需要哪些功能，從而縮小範圍並幫助您儘可能提供更多的價值。