Great work!

XP to next level

BugEater

Given — Setting the Context

Learning Objectives

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

  • Explain the precise purpose of a Given step
  • Write Given steps that describe state, not actions
  • Spot a common mistake: sneaking an action into a Given

Given Sets the Stage, It Doesn't Act

Given establishes the world as it exists before anything interesting happens. It answers the question: "what must already be true for this scenario to make sense?"

Given a registered user with a valid session
Given an empty shopping cart
Given a discount code "SAVE10" that expired yesterday

Each of these describes a state — a fact about the world — not something the user or system is doing right now.

The Mistake: Actions Disguised as Given

A common beginner error is writing a Given that actually performs an action:

# Wrong — this is an action, not a precondition
Given the user clicks "Add to Cart"

Clicking is something that happens, not something that is. The corrected version separates the state from the action:

Given an empty shopping cart
When the user adds an item to the cart

Now Given describes the starting state, and the click (the actual trigger) correctly belongs in When — which you'll study in the next lesson.

Multiple Given Steps

A scenario can have more than one Given, each adding a fact to the setup:

Given a registered user with a valid session
Given a cart containing one item priced at $50
Given a discount code "SAVE10" that is currently active

In practice, these are usually chained with And for readability (covered later in this module), but understanding that each line is logically still a Given — a precondition — matters more than the keyword used to write it.

Why This Matters for Business Readers

A well-written Given block is often the part of a scenario a business analyst scrutinizes most closely — it's where assumptions live. "Given a discount code that expired yesterday" makes an implicit business rule ("expired codes should behave differently from active ones") explicit and reviewable, long before anyone writes code.

Pro Tip: If your Given step contains a verb like "clicks," "submits," or "enters," stop — you've probably written a When in disguise.

Key Takeaways

  • Given describes state that already exists, never an action being performed
  • A Given step containing a UI action verb is a common beginner mistake
  • Multiple Given steps can build up a complete precondition
  • Business readers often scrutinize Given steps closely, because that's where assumptions become explicit

Quiz

What question does a Given step answer?

What is wrong with the step "Given the user clicks 'Add to Cart'"?

Why do business analysts often scrutinize Given steps closely?

What is the clearest sign that a Given step was actually written as a When step in disguise?