Last time, I proposed potential solutions to challenge 2. This time I read through what the community came up with. This is my summary of the lessons learned.

Tip 1 - Scenario Description?

It’s refreshing to know that I can add an additional description right under the scenario. (Pay attention to the indentation)

Scenario Outline: duplicated emails should be prevented

   Email is case insensitive. GMail is a very popular system so
   many users will register with gmail emails. Sometimes they use
   gmail aliases or labels.
   To prevent users mistakenly registering for multiple accounts
   the user repository should recognise common Gmail tricks.
...

I didn’t know you could do this. Previously, when writing scenarios, I assumed I was limited to two things:

  1. Choose a meaningful and obvious scenario name and
  2. The Given When Then steps should be clear to explain what is going on.

However, I did feel somewhat limited because I would sometimes add comments after each step to add more clarity.

Tip 2 - Examples with a description

Notice how there is a comment column provided in the examples. It’s not used for test automation but provides clarity on each of the variation of gmail emails here.

Given a user repository with the following users:
| username | personal name | email            |
| mike     | Mike Smith    | mike@gmail.com   |
When the Steve James tries to register with username steve123 and <email>
Then the registration should fail with "Email already registered"

Examples:

| comment                                                    | email               |
| google ignores dots in an email, so mi.ke is equal to mike | mi.ke@gmail.com     |
| google allows setting labels by adding +label to an email  | mike+test@gmail.com |
| emails should be case insensitive                          | Mike@gmail.com      |                           
| domains should be case insensitive                         | mike@Gmail.com      |
| googlemail is a equivalent alias for gmail                 | mike@googlemail.com |

Tip 3 - Example groups

If the Given When Then steps are all the same between scenario outlines, consider combining them into one (see below). This is a big improvement than my idea in my last post which was - use multiple scenario outlines. This technique saves the repeating of steps and again keeps it tidy.

Given a user repository with the following users:
| username | personal name | email            |
| mike     | Mike Smith    | mike@gmail.com   |
When the Steve James tries to register with username steve123 and <email>
Then the registration should fail with "Email already registered"

Examples: uppercase/lowercase aliases should be detected

| comment                                                    | email               |
| emails should be case insensitive                          | Mike@yahoo.com      |
| domains should be case insensitive                         | mike@Yahoo.com      |
| unicode normalisation tricks should be detected            | mᴵke@yahoo.com      |

Examples: gmail aliases should be detected

| comment                                                    | email               |
| google ignores dots in an email, so mi.ke is equal to mike | mi.ke@gmail.com     |
| google allows setting labels by adding +label to an email  | mike+test@gmail.com |
| googlemail is a equivalent alias for gmail                 | mike@googlemail.com |

Tip 4 - Use a ‘framing example’

It’s easy for me to busy myself bashing out a list of scenarios, the flow of the feature file can be overlooked. This is where this tip comes in handy. In their post, they referred to it as a ‘framing scenario’ and they describe it like this:

That scenario should be simple in terms of domain rules, and it should not try to explain difficult boundaries. It’s there to help readers understand the structure, not to prevent problems. A good choice is usually a “happy day” case that demonstrates the common flow by showing the full structure of data.

Here is the example of the gherkin:

Feature: Preventing duplicated registrations

Scenario: Successful registration
...
Scenario: allowing duplicated personal names
...
Scenario outline: preventing duplicated emails
...
Scenario outline: preventing GMail aliases
...

Simply put, it’s a reminder to revisit the flow in the feature’s structure.