How to Structure CRUD Tests using BDD

Question

I'm stuck at a bit of a quandary trying to figure out the best way of structuring my CRUD tests. Within my application users have the ability to create several types of 'tasks'. My currently implementation looks something like the following:

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

The reason I'm looking for help here is because I'm having trouble controlling execution order of the CRUD steps. I'm using Specflow and NUnit which executes the scenarios in alphabetical order rather than the order they appear in the feature file. Which results in this order C > D > R > U, which of course crashes and burns when run.

I tried adding characters to the beginning of the scenario name, resulting in something like this "Scenario: Phase 1 Create...", "Scenario: Phase 2 Read...", and so on. But as I was making this change I could not help but thinking how 'hack-ish' it felt. I've done some research but have for the most part come up empty on a better way to control the execution order.

I do have multiple of these CRUD tests to write; one for each type of 'task' and I'm wondering would it be better to try and condense the entire CRUD stack into a single scenario so I don't have to worry about execution order or is there a better way to control the execution?

Answer 1

After some internal debate I decided that it was futile to try and reduce the tests I had already written into the BDD grammar of:

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

And what I ended up with was something like this:

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

    [pre-condition]
    [action]
    [observation] 

    ...
    [end]

Here's what it looks like with the original code.

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

I'm sure some will disagree with my approach since it breaks the BDD grammar, but you should know this executes perfectly fine while maintaining all the precision of the individual scenarios as well as readability.

Answer 2

Relying on the order of execution of the scenarios is an anti-pattern and should be avoided. Test runners usually don't provide any mechanism to control the order of execution for the same reason. It would be also against the concept of an executable specification: the scenario should be understandable (and executable) on its own.
Source: Specflow - State between "scenarios"

So, I recommend use one scenario or, if you want separate scenarios, just make them independent on an execution order.
For instance, for Delete scenario you should perform CRU preconditions into this scenario and then execute Delete steps with verifications.
For best practices (IMHO) - see Kent Beck article: https://www.facebook.com/notes/kent-beck/decompose-run-on-tests/555371804495688

Answer 3

Put the complete CRUD Sequence in one Scenario. Choose intelligent scenario names and an expressive goal on scenario level, but keep freedom how a single CRUD sequence may look like. I made very good experiences with that principle, even it was hard to me as well.

Make sure that a Scenario keeps your "System under test" clean and "as unchanged as possible", after it's execution.

And if you wonder about growing feature files: Read your scenario titles, and I think you have the step names for the next level of test. That means:

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

You definitely cannot and should not rely on the order of execution of your scenarios. Sooner or later you will run into trouble (at least, I did).

However, it happens a lot that a feature file, then, only holds one single scenario. :-)