如何使用BDD構建CRUD測試

我陷入了一個窘境，試圖找出構建我的CRUD測試的方式最佳。在我的應用程序中，用戶可以創建多種類型的「任務」。我目前實現看起來像下面這樣：如何使用BDD構建CRUD測試

Scenario: Create Task-Type A 
Given I am on a user's profile page 
And Have access to create tasks 
When I create a new task with a unique title and description 
Then The confirmation prompt should display 

Scenario: Read the Task-Type A 
Given A new task was created 
When I search the text on the page for the unique title 
Then I should find the task 
And All the details of the task should match what was created 

Scenario: Update the Task-Type A 
Given A task exists 
And I have opened the edit dialog 
When I make the following changes: 
| title | description | date | save | 
| "" | ""   | "" | yes | 
Then all the saved changes should match the task details 

Scenario: Delete the Take-Type A 
Given A task exist 
When I select the option to delete 
And I confirm deletion process 
Then The Task should no longer exist in the list

我尋求幫助，在這裏是因爲我無法控制的CRUD步驟執行順序的原因。我使用的是Specflow和NUnit，它按字母順序執行場景，而不是它們在特性文件中出現的順序。這導致這個順序C> D> R> U，這在運行時當然會崩潰和燃燒。

我試圖在場景名稱的開頭添加字符，導致類似於「場景：階段1創建...」，「場景：階段2讀取...」等內容。但是，當我做出這個改變時，我忍不住想到它的感覺如何「黑暗」。我已經做了一些研究，但大部分都是用空白來更好地控制執行順序。

我確實有多個這些CRUD測試要寫入;每種類型的「任務」都有一個，我想知道是否最好將整個CRUD堆棧壓縮到一個場景中，這樣我就不必擔心執行順序，還是有更好的方法來控制執行？

來源

2014-04-29 Austin

一些內部辯論時，我決定，這是徒勞的嘗試和減少我已經寫進BDD語法測試以後：

[scenario name] 
    [pre-condition] 
    [action] 
    [observation]

什麼我結束了成這個樣子了：

[scenario name] 
    [pre-condition] 
    [action] 
    [observation] 

    [pre-condition] 
    [action] 
    [observation] 

    ... 
    [end]

下面是它與原始代碼的相似之處。

Scenario: Create Task-Type A 
Given I am on a user's profile page 
And Have access to create tasks 
When I create a new task with a unique title and description 
Then The confirmation prompt should display 

Given A new task was created 
When I search the text on the page for the unique title 
Then I should find the task 
And All the details of the task should match what was created 

Given A task exists 
And I have opened the edit dialog 
When I make the following changes: 
| title | description | date | save | 
| "" | ""   | "" | yes | 
Then all the saved changes should match the task details 

Given A task exist 
When I select the option to delete 
And I confirm deletion process 
Then The Task should no longer exist in the list

我敢肯定有些人會用我的做法不以爲然，因爲它打破了BDD語法，但你應該知道這個執行完美的罰款，同時保持單個方案的所有精度和可讀性。

來源

2014-05-01 14:00:43 Austin

依靠場景的執行順序是反模式，應該避免。出於同樣的原因，測試運動員通常不會提供任何控制執行順序的機制。這也違背了可執行規範的概念：該方案應該是可以理解的（並且可執行）。
來源：Specflow - State between "scenarios"

所以，我建議使用一個場景或者，如果你想獨立的場景，只是讓他們獨立的執行順序。
例如，對於刪除方案，您應該在此方案中執行CRU前提條件，然後執行刪除步驟和驗證。
有關最佳實踐（恕我直言） - 請參閱Kent Beck文章：https://www.facebook.com/notes/kent-beck/decompose-run-on-tests/555371804495688

來源

2014-04-29 18:26:40 drets

將完整的CRUD序列放入一個場景中。在情景級別選擇智能場景名稱和富有表現力的目標，但要保持單個CRUD序列的外觀。我對這個原則做了很好的體驗，即使對我來說也很難。

確保場景在執行後讓您的「待測系統」保持乾淨並「儘可能不變」。

如果您想知道如何增加功能文件：請閱讀您的場景標題，並且我認爲您有下一級別測試的步驟名稱。這意味着：

Feature: Example 
    Scenario: Process Task A 
     Given I create Task A 
     When I read Task A 
     Then I update Task A 
     Then I delete Task A

您絕對不能也不應該依賴於您的方案的執行順序。遲早你會遇到麻煩（至少，我做到了）。

然而，很多情況下，功能文件只能保存一個場景。:-)

來源

2014-04-29 21:36:34 realtime

如何使用BDD構建CRUD測試

回答

相關問題