Last time, I wrote about possible solutions to challenge 1. This time I read through what the community said posted by Gojko Adzic. I’m not going to go through all of them in detail, these are my mini summaries for my own reference later.
Describe what exists instead
Don’t say ‘There is no spoon’, say the positive
Given list of users is empty.
Ask an extreme question
What does it mean for a user not to exist? Were they not born yet?
Haha, it’s basically the first part of my last post. Clarify!
Provide a meaningful domain name
When Gojko says ‘domain’, he doesn’t mean ‘google.com’. He is referring to a business term that the team can understand. In the case of ‘Given the user does not exist’, you must ask ‘Where does it not exist?’.
Gojko uses the term ‘repository’ to represent a box that contains the possible ‘list’ of users which is more explicit than just saying ‘Given the user does not exist’
Given a user repository with the following users | username | personal name | | mike | Mike Smith | | steve123 | Steve James | When John Michaels attempts to register with the username "john" Then the user repository should contain the following users: | username | personal name | | mike | Mike Smith | | steve123 | Steve James | | john | John Michaels |
Now we know if there is no spoon or not, we see through everything.
Nothing much new here. Basically, what I said before, map out all possibilities of what it means for a user account to be unique.
Extract scenario outlines
Yes, I mentioned this in the last post! Although, their version is way more expanded and clear than what I came up with.
Scenario Outline: Users with existing emails or usernames should be rejected Given a user repository with the following users: | username | personal name | email | | mike | Mike Smith | email@example.com | | steve123 | Steve James | firstname.lastname@example.org | When the Tony James tries to register with <requested username> and <email> Then the registration should fail with <registration message> And user repository should contain only the following users: | username | personal name | email | | mike | Mike Smith | email@example.com | | steve123 | Steve James | firstname.lastname@example.org | Examples: | requested username | email | registration message | | steve123 | email@example.com | Username taken | | steve456 | firstname.lastname@example.org | Email already registered |
Although we’re currently writing out tests in Gherkin at the moment, nobody sees them apart from testers. This is definitely something to keep in mind if we integrate the three amigos model into our business workflow.
Probe for boundaries
This bit really expands on the edge cases, Gojko mentioned points that I didn’t think of before:
- What about case sensitivity in emails? (email@example.com vs Steve@Yahoo.com)
- What about very similar emails like firstname.lastname@example.org and email@example.com?
- What about symbols in usernames? (steve.o vs steve_o)