This is my first foray into the first post of an series of challenges on the Specflow website. The point is, what do you do when you’re setting up a user that does not yet exist?
I’ve pasted the text taken from the link above:
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
You can write scenarios this way to ensure that the system creates unique accounts. But could it be clearer? Can you see how it can be vague? For example, what does the name ‘John’ express? The first name or the email?
- It’s vague
- The test data problem
- One scenario or two?
To begin, the question itself already reveals one of the answers. What does ‘John’ mean and how do we determine an account is a duplicate? The scenarios are not specific enough developed by a coder. That is the first step, map out all the possible critical paths. A few come to mind:
- Duplicate username
- Duplicate email address
- Duplicate first name AND surname
- Spammy email domains (such as throw away email accounts)
Also, it might be worth pointing out that ‘Then the registration is successful’ (or fail) is also vague. How do we know it’s successful? Will it show a display message? Will the data be set up in the database? There is no right or wrong here. Depending on the project that you’re working on, you may not even need to specify and that’s ok.
Let’s say we were going to base it upon the email address. If we were to improve it, we would now have something like this.
Given user account with email "firstname.lastname@example.org" does not exist When a user tries to register with "email@example.com" Then the registration is successful Given user account with email "firstname.lastname@example.org" exists When "email@example.com" tries to register Then the registration fails
The test data problem
This looks better, doesn’t it? But there is a second issue which relates to test automation. The tricky part is setting up test data (aka setup and teardown). In other words, what if we finished running the automated tests and need to repeat them? “firstname.lastname@example.org” will now exist in the database so the first scenario will fail. Easy solution, don’t talk about john.
When a new user tries to register (email does not exist) Then the registration is successful When an existing user tries to register (email does exist) Then the registration fails
Under the hood, we could generate random data when automating tests.
One scenario or two?
These scenarios have a single action of ‘register’, so we can combine them into a scenario outline.
Scenario Outline: A user can only register once Given there is a user with email in <State> When the user attempts to register Then the registration is <Outcome> Examples: |State|Outcome| |Exists|Success| |Does not Exist|Failure|
I know that saying ‘user’ is may not the best practice here since it means nothing. A further improvement might even be to call it ‘customer’ or what makes sense in your business.