Here is the next challenge Specflow put out, I’ve bolded the key parts they want to address. They should put the ‘s’ on ‘challenge’ because they have outlined more than one issue here.

The next challenge

This brings us to the challenge for the next week. Let’s say that we actually do want to be a bit more strict about preventing the same person from registering twice, so all those Gmail hacks need to be handled. Plus the support managers came back and said that they liked the idea of avoiding problems with usernames that are too similar. This will lead to dozens, if not hundreds of examples. Alister also looks at examples around password complexity, which is another common aspect of registration that we might want to add to the registration feature. Putting it all into a single scenario outline is definitely not a good idea. How would you better structure such a big list of examples, so it’s easy to understand and maintain?

The answer is revealed in the question itself.

Putting it all into a single scenario outline is definitely not a good idea. How would you better structure such a big list of examples, so it’s easy to understand and maintain?

We should not lump a bunch of different scenarios together so the way I have split it up (by bolding) makes it clearer. The overarching theme is “How do you structure a long list of examples?”, but they have pointed out the 3 specific issues:

  1. Gmail hacks such as steveo+spam@yahoo.com vs steveo+spam2@yahoo.com
  2. Similar usernames such as steve.o vs steve_o
  3. Password complexity

This way, we can address each one in turn more easily during discussions between developers and project managers. Within each of these scenarios, more clarity may be required in order to determine the rules around uniqueness (1 and 2) and logic (3). When we have clarified the rules further with any edge cases, we can lay them out using scenario outlines.

For this post, I will concentrate on number 1.

1 - Gmail Hacks

A first crack at this in Gherkin would get me something like this:

Scenario Outline: Only accept registration from unique Gmail accounts

Given a user repository with the following users:
| username | personal name | email            |
| mike     | Mike Smith    | mike@gmail.com   |
When Mike Smith tries to register with  <email>
Then the registration should display <registration message>
And the user repository should contain only the following users:
| username | personal name | email            |
| mike     | Mike Smith    | mike@gmail.com   |

Examples:
| email             | registration message      |
| mike+news@gmail.com  | Email already registered |
| mike+readlater@gmail.com   | Email already registered |

We can see from the examples that if someone attempts to use a plus icon alias, they will not be able to proceed with the registration. However, by writing this scenario, more questions are brought into the light:

  1. Is the plus icon the only method of an alias for a Gmail account?
  2. What about other email providers other than Gmail?
  3. Can a new user register with an alias to begin with or must it be a pure email address?

It’s evident that more research is required to explore other methods someone could adopt in terms of email aliases, if any. Point 2 is also important because the plus icon might actually be a completely different email address for another provider. Without digging deeper, we won’t know.

Let’s say we have done all the research now and the examples list is still too long (this is what the challenge is about):

Approach 1 - Long list of examples

...
Examples:
| email             | registration message      |
| mike+news@gmail.com  | Email already registered |
| mike+readlater@gmail.com   | Email already registered |
| mike2+news@yahoo.com | Registration successful |
| mike+readlater@yahoo.com   | Email already registered |
| mike2+news@hotmail.com | Registration successful |
| mike+readlater@hotmail.com   | Email already registered |
| mike2+news@live.com | Registration successful |
| mike+readlater@live.com   | Email already registered |
| mike2+news@msn.com | Registration successful |

Horrible, we could keep going on and on for eternity.

Approach 2 - Split it up by provider

Hmm, maybe we can split it up into smaller scenario outlines?

Scenario Outline: Only accept registration from unique Gmail accounts
Examples: (fill in the blank)

Scenario Outline: Only accept registration from unique Yahoo accounts
Examples: (fill in the blank)

Scenario Outline: Only accept registration from unique MSN accounts
Examples: (fill in the blank)

Still horrible. Again, we could keep going on and on for eternity.

Yes it is a small improvement and a little more readable. However, it’s repetitive and a pain to maintain for all the email providers in the world.

Approach 3 - Split it up by scenario

A scenario is meant to capture a scenario (duh), not be another list of repeated steps. In other words, each scenario should be unique, not a duplication of another one.

In my first attempt at the Gherkin, I named the scenario “Scenario Outline: Only accept registration from unique Gmail accounts”. If the aim of this scenario is to capture unique email accounts then why mention Gmail at all? Here is an improvement on that.

Note: Let’s pretend that Yahoo supports the same alias functionality as Gmail but Apple does not.

Scenario Outline: Only accept registration from unique email accounts

Given a user repository with the following users:
| email            |
| mike@gmail.com   |
| david@yahoo.com |
| john@icloud.com |
When a new user tries to register with  <email>
Then the registration should display <registration message>
And the user repository should contain only the following users:
| email            |
| mike@gmail.com   |
| david@yahoo.com |
| john@icloud.com |
| john+news@icloud.com |

Examples:
| email             | registration message      |
| mike+news@gmail.com  | Email already registered |
| david+news@yahoo.com   | Email already registered |
| john+news@icloud.com   | Registration successful |

Better, we successfully satisfied the meaning of ‘Scenario’ here and provided a limit set of examples to demonstrate what is going on here. Of course, there are many providers but it’s overkill to include them all. More examples will not add more value than it already describes.

If we add automated testing to the equation, perhaps further testing can be completed outside of the provided table of examples if needed.