One Step, Many Fields

Learning Objectives

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

• Recognize the "wall of And" anti-pattern in a scenario's Given or When block
• Explain why chaining one step per field is a readability and maintenance problem, not just a style preference
• Describe, at a preview level, the two structures — Data Tables and Doc Strings — that solve this problem

The Wall of And

Imagine testing a user registration form. Written the obvious way, one field at a time, the scenario looks like this:

Scenario: A visitor registers a new account
  Given the user is on the registration page
  And the user enters "Jane" into the first name field
  And the user enters "Doe" into the last name field
  And the user enters "jane.doe@example.com" into the email field
  And the user enters "Sup3rSecret!" into the password field
  And the user enters "+1-555-0100" into the phone field
  And the user enters "42 Baker Street" into the address field
  And the user enters "London" into the city field
  And the user enters "NW1 6XE" into the postal code field
  And the user enters "United Kingdom" into the country field
  And the user checks the marketing consent checkbox
  When the user submits the registration form
  Then the account is created successfully

Every line compiles. Every line is technically valid Gherkin. And the scenario is still a mess.

Why This Is a Problem

Ten near-identical And lines cause three concrete problems:

1. The signal drowns in the noise. The one line that actually matters — When the user submits the registration form — is buried at the bottom of a wall that looks the same from a distance. A reviewer skimming this scenario has to read every line just to find where the actual action happens.
2. It doesn't scale. Add a "date of birth" field to the form next sprint, and you're now editing this pattern in every scenario that touches registration — and every similar scenario elsewhere in the suite.
3. It hides the relationship between the fields. These ten values aren't ten independent facts — they're one object: "the registration data." Writing them as ten separate steps throws away that structure, and forces both the reader and the automation layer to reassemble it by hand.

None of this means the data is the problem. Ten fields for a registration form is completely reasonable. The problem is entirely in how the data is shaped on the page.

Two Fixes, Previewed

Gherkin gives you two purpose-built structures to attach richer data to a single step instead of exploding it into a chain of And lines. You'll study each in depth in the next two lessons, but here's the shape of each:

Data Tables attach a | key | value | grid directly under one step, so the entire registration form becomes a single Given with a table beneath it — one step, ten rows of structured data, zero repeated And steps. This is the right tool whenever your data is naturally tabular: a fixed set of named fields, or several rows that share the same columns.

Doc Strings attach a """-delimited block of free text directly under a step, for content that isn't structured as fields at all — a paragraph of justification text, an email body, a block of legal terms. You wouldn't build a table for a paragraph; you'd lose the very thing that makes it a paragraph.

Pro Tip: If you can draw a box around your And chain and label it "this is really one thing," that's your cue to reach for a Data Table or a Doc String instead of more And lines.

Key Takeaways

• A chain of near-identical And steps, one per field, is the "wall of And" anti-pattern
• The problem isn't the number of data points — it's spreading one logical object across many steps
• Walls of And bury the meaningful trigger step and don't scale as forms grow
• Data Tables solve this for structured, tabular data; Doc Strings solve it for free-form text
• Both are covered in depth in the next two lessons