Step Conjunction

Learning Objectives

By the end of this lesson you will be able to:

Identify a conjunction step by its telltale comma-joined actions
Explain the three concrete costs of leaving conjunction steps in a spec
Refactor a conjunction step into a proper step chain or a single declarative action

What a Conjunction Step Looks Like

A conjunction step packs two or three actions into a single line, usually joined with commas or repeated "and"s inside the sentence itself:

When the user enters their email, enters their password, and clicks submit

At a glance it reads fine — it's grammatically correct English. That's exactly what makes it dangerous: it slips past review because nothing looks wrong, even though it's doing the job of three steps while pretending to be one.

Why It's a Problem

It hides which action actually matters. In the example above, is the scenario about the email field, the password field, or the submit action? A single conjunction step gives all three equal weight, so a reader can't tell which part the scenario is actually there to verify.

It can't be reused or reordered. Step definitions are meant to be composable building blocks. "Enters email, enters password, and clicks submit" as one step can never be reused for a scenario that needs just the login form filled in without submitting, or that submits in a different order to test a validation rule.

It buries the defect location. If this step fails, the failure message points at the entire three-action line. Was it the email field? The password field? The button? You've lost the precision that separate steps would have given you for free.

The Fix: Split It Up

The straightforward fix is a proper When/And chain, one action per line:

When the user enters their email
And the user enters their password
And the user submits the login form

Now each action is independently reusable, independently reportable on failure, and the scenario reads as a sequence rather than a run-on sentence.

The Better Fix: Abstract to One Action

Often, the three actions aren't actually three separate concerns for the business rule being tested — they're just how a login happens to be implemented in the UI. If the scenario doesn't care about the individual fields, collapse them into one declarative step:

When the user logs in with valid credentials

This is the more powerful fix. It hides the implementation detail entirely, is trivially reusable across every scenario that needs a logged-in user, and reads as a single, real business action — which is what a When step is supposed to be in the first place.

Choosing between "split into a chain" and "abstract to one step" comes down to one question: does this scenario actually care about the individual sub-actions? If yes, keep them visible as a chain. If no, hide them behind one clean step.

Pro Tip: If you find yourself counting commas or "and"s inside a single step's sentence (not the Gherkin And keyword, but the English word buried in the text), that step is very likely a conjunction step in disguise.

Key Takeaways

A conjunction step joins two or three actions with commas or "and" inside a single line — grammatically fine, structurally broken
It hides which action matters, resists reuse and reordering, and buries the defect location on failure
Fix it by splitting into a When/And chain, or better, abstracting it into one declarative business action when the sub-actions don't matter to the scenario