Chapter 1: The Role of "Should" in Gherkins

When it comes to writing Gherkin statements, the use of "should" may seem optional, but it is actually essential!

In earlier discussions, I have extensively covered Gherkin and highlighted various techniques for enhancing their composition. For instance, one article detailed five key considerations that are often overlooked in typical training courses. Additionally, I have referenced another article offering 15 practical tips, which I use as a checklist to evaluate my students. Among these tips, one stands out as particularly significant:

Always Use "Should" in "Then" Statements

The concept is straightforward: whenever you write a Gherkin and utilize the "Then" keyword, incorporating "should" is necessary. Here’s a comparison:

# Incorrect

Scenario: User withdraws cash from ATM

Given the user's balance is $200

When the user withdraws $100 from the ATM

Then the user's balance is $100

# Correct

Scenario: User withdraws cash from ATM

Given the user's balance is $200

When the user withdraws $100 from the ATM

Then the user's balance should be $100

Over time, I have realized that this simple yet effective guideline has raised some questions. Let’s address them.

Why Use "Should" Instead of Omitting It?

The statement "Then the user's balance is $100" is technically acceptable, yet it fails to clearly assert or verify an outcome. This lack of clarity is problematic. Often, "Then" statements can imply an action, preparation, or change, which they are not intended to do. Instead, "Then" statements should strictly express the intent to verify or assert a result, which can be challenging.

In the example above, the same wording is utilized in both "Given" and "Then." This dual use can create ambiguity; Gherkins should strive for clarity in communication.

Why Not Use Future Tense?

Using "Then the user's balance will be $100" shifts the focus from validating a result to making a prediction. This phrasing can introduce ambiguity, which Gherkin seeks to eliminate.

Gherkin statements should reflect the system's state as it ought to be after executing the preceding steps. It's not about what will happen later, but rather what should be true immediately following the actions taken.

Utilizing future tense implies that the condition may not yet hold true, which can lead to confusion. Instead of relying on future tense, it’s better to frame your statements in the present.

# Incorrect

Scenario: User withdraws cash from ATM

Given the user's balance is $200

When the user withdraws $100 from the ATM

Then the user's balance will be $100

# Correct

Scenario: User withdraws cash from ATM

Given the user's balance is $200

When the user withdraws $100 from the ATM

And the user retrieves the cash from the ATM

Then the user's balance should be $100

Why "Should" Instead of "Expect"?

Using "Then expect the user's balance to be $100" does address some of the issues previously mentioned, but it reads more like a command or a piece of code rather than a natural sentence. While you could use "expect" if that’s your team's preference, "should" is generally favored for its more declarative tone, making it easier for non-technical team members, like product owners or business analysts, to understand.

Since Gherkin aims to facilitate communication across various roles in a team, avoiding "expect" in favor of "should" is advisable.

Why "Should" Instead of "Must"?

The phrase "Then the user's balance must be $100" conveys a strong obligation, clearly indicating that the condition is essential for the test's success. However, "should" is often preferred due to its softer tone.

Using "must" can come across as harsh and may hinder collaborative dialogue. In contrast, "should" allows for flexibility and encourages discussion around requirements, which is vital for effective teamwork.

You might think that "must" denotes obligation while "should" implies optionality. In everyday language, "should" can indeed suggest a recommendation. However, in the context of Gherkin and Behavior-Driven Development (BDD), "should" does not imply optionality. It states a clear expectation about the system's behavior.

When we say "Then the user's balance should be $100," we are expressing an anticipated outcome based on prior actions. If the balance doesn't match this expectation, the scenario fails, signaling a potential issue within the system.

In summary, while "should" can imply optionality in casual conversation, in Gherkin it serves to define explicit expectations. It provides clarity and precision to "Then" statements, transforming them into clear assertions. This approach not only enhances readability but also promotes inclusivity in communication.

Now you understand why using "should" in your "Then" statements is crucial for effective Gherkin writing.

Chapter 2: Helpful Resources

Explore whether all your test cases should be written in Gherkin format in this informative video.

Discover five compelling reasons to space your Cucumber tests effectively in this engaging video.