Best practices
Data-driven design
Separate what a scenario does from the data it runs on.
What you'll learn
When to use Scenario Outlines, datasets or factories, how to keep environment-specific data out of features, and how to name rows so failures are readable.
| Need | Use |
|---|---|
| a handful of variants that document behaviour | Scenario Outline with a # title-format: comment |
| many rows, or rows that differ per environment | a CSV, JSON or YAML dataset resolved per environment |
| unique data on every run | a factory seeded by the scenario fingerprint |
| accounts | the user pool, never literal credentials |
| large relational data | a db dataset in a td_<slug>_<name> table seeded with automax data import |
Keep business values in data files and structure in features:
Given I load dataset "shipping" where "country" is "DE"
When I check out with "{{firstName}}" "{{lastName}}" "{{postalCode}}"
Then I should see the text "{{expectedTax}}"Give datasets a stable identifier column so failures point to a row, and keep data/common as the baseline every environment inherits.