Gojko Adzic has started a series of challenges on the Specflow blog where readers can submit solutions to common problems writing automated tests using gherkin (Given/When/Then).
The first challenge is:
“What’s the best way to describe a Given for a value that’s not supposed to be there? For example, starting the specification from a point of a user who does not yet exist in a database, or a product that’s not been set up. “Given a user that doesn’t exist” sounds vague, but “Given user John that does not exist” sounds silly – how can we talk about John if he doesn’t exist yet?”
Given user John does not exist When John tries to register Then the registration is successful Given user John exists When John tries to register Then the registration fails
“How would you improve the scenario of our example to solve the challenge of this week?“Gojko Adzic
Interestingly this problem highlights the issues I found using Gherkin to specify business rules and examples I previously wrote about:
“I’m not keen on writing specifications in gherkin (Given/When/Then) as I think it’s too generic and frequently makes the feature specifications too verbose – and takes emphasis away from the critical parts.”Example of lightweight feature documentation
I prefer bullet points and tables.
I’d specify the above scenarios as follows.
- A user can only register a single account per unique email address
- A user’s email address is their username
- A user can register using their Google or Facebook account without having to enter a username or password
- A user must enter a password unless they are registering using Google or Facebook
- Passwords must contain at least 4 letters and 4 digits
- Passwords are maximum length of 10 and can contain any ASCII characters
|Scenario||Example Email Address||Result|
|New user signs up with a new email@example.com||✅ Registration Successful|
|New user signs up with a new email and invalid firstname.lastname@example.org||❌ Registration Unsuccessful – Validation Error Displayed and no account created|
|User attempts to sign up with email already registered email for account with email@example.com||❌ Registration Unsuccessful – Reset password page displayed with email prefilled|
|User attempts to sign up with email already registered email for account with Google firstname.lastname@example.org||❌ Registration Unsuccessful – Log in with Google page displayed|
It’s tempting to put passwords into the above table, which is what I originally did, but I’ve found it’s better to specify those separately (in the same document).
|Password Scenario||Example Password||Valid/Invalid|
|Less than 8 characters||123||❌|
|Less than 4 digits||aaaabbbb||❌|
|Less than 4 letters||123456aa||❌|
|No emoji – ASCII Chars Only||1234abcd💀||❌|
|More than 10 characters||123456abcdef||❌|
|10 Characters with ASCII||1234abcd%$||✅|
|4 digits and 4 letters||abcd1234||✅|
|Special characters don’t count as letters||abc$1234||❌|
Whilst these scenarios aren’t gherkin I don’t think they need to be. They could be taken by developers and written as unit tests alongside the code. I wouldn’t have an e2e automated test that tests this logic at this level – it’s complex and an expensive waste of time.
I’ll be interested to see the follow up posts about the best way to specify these in gherkin, as I can’t see a clearer way than just using bullet points and tables 🙌