Gherkin style guidelines for CRUD operations

[Naresh Bhatia]

Simple question - what's the preferred way to write CRUD scenarios. For example:

Scenario: Account Creation

Option 1

When I create an account called "My Retirement Account"

And I ask for the account

Then I get an account called "My Retirement Account"

Option 2 (eliminate 'And I ask for the account')

When I create an account called "My Retirement Account"

Then the account should exist

Option 3 ('Given' and 'When' do the exact same creation, but 'Given' is more reusable)

Given I have an account "My Retirement Account"

When I ask for the account

Then I get an account called "My Retirement Account"

Option 4 (often I will need to create more than one accounts, so why not make a more reusable step)

Given I have the following accounts

    | name                  |

    | My Checking Account   |

    | My Retirement Account |

When I ask for my accounts

I should get the following accounts

    | name                  |

    | My Checking Account   |

    | My Retirement Account |

[Roberto Lo Giacco]

Il giorno martedì 6 ottobre 2015 16:24:19 UTC+2, Naresh Bhatia ha scritto:

Simple question - what's the preferred way to write CRUD scenarios. For example:

I believe those represent different scenarios rather than four ways to describe the same scenario. On top of that they are worded in an IT language rather than a business language. What is the benefit of creating an account? Please do not consider Cucumber as a way to drive your tests, but as a way to document your system...

Speaking about scenarios differences, option 1 and 2 are very similar, but I fail to see the business benefit. Option 3, on the other hand, represents a different scenario, as the account is pre-existing, so it's describing the feature to be able to browse the accounts list when only one account exists. Finally option 4 represents a multi account scenario, where I ensure all of the accounts are visible.

So, imagining you are describing a feature "account management console" I can see these scenarios:

• no accounts to list
• one account to list
  
• multiple accounts to list
  
• create a new account
• creation of a new conflicting account is blocked
• batch creation of multiple accounts
• batch creation of multiple accounts, some conflicting, with errors reported
• account deletion, confirmation screen
• account update possibility

and so forth...

I'm not describing all the tests (what happens if I have multiple accounts and I attempt to create a new one?) but the feature I'm going to provide and using a terminology which makes sense to the business/product owner/client

Roberto

[Naresh Bhatia]

Thanks for your insights, Roberto. I think the key for me is your advice that the scenarios should be worded in a business language. I was thinking very technical!

Thanks, again.

Naresh

[Andrew Premdas]

A key idea when writing scenarios is to think about describing 'what' you are doing (in this case creating accounts) and 'why' you are doing it. There seems to be a couple of interesting points in the scenarios you have given which should be explained.

1. That users can have more than one account? Why?

2. That users can name their accounts. Why can they do this?

The most important part (imo) of a scenario is the context it exists in, which often is ignored. If we explore the idea of named accounts we might get something like

Feature: Named Accounts

  As a user with more than one account

  I want to name my accounts

  So I can differentiate between them without using the account number

Scenario: Create a named account

  When I create an account called 'foo'

  And I view my accounts

  Then I should see an account 'foo'

Starting from here all sorts of ideas for scenarios should appear e.g.

Scenario: Rename an account

Scenario: Give an existing account a name

Scenario: Creating an account with a duplicate name
...

So what we are doing is using the feature to explore the idea of named accounts.

At all points in this process we should be 'popping the why stack'. So

Q. Why do we need named accounts?

A. Because this allows user to differentiate between accounts

Q. Why can't we just use the account number to differentiate?

A. ...

etc.

This is a very different process to implementing a scenario and should be done first, ideally in collaboration.

All best

Andrew

--
Posting rules: http://cukes.info/posting-rules.html
---
You received this message because you are subscribed to the Google Groups "Cukes" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cukes+un...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

------------------------

Andrew Premdas

blog.andrew.premdas.org

[Naresh Bhatia]

Thanks, Andrew. That's great guidance! It is amazing that I have probably read similar advice in several articles, but it did not sink in until I started thinking about it with concrete examples.

Thanks again for taking the time for your thoughtful response.

Naresh Bhatia