Q25 of 40 · Karate
How would you parametrise the same scenario over a Karate Examples: block?
KarateMidkaratescenario-outlineexamplesparameterized-testsdata-driven
Short answer
Short answer: Use Scenario Outline: with Examples: — column headers become <placeholder> variables substituted into steps. Each row produces one independent scenario execution. For complex JSON payloads, pass JSON as a table column value or use the call-with-array pattern with a JSON file instead.
Detail
Basic Scenario Outline:
Scenario Outline: <method> <path> returns <expected>
Given url baseUrl
When method <method>
Given path <path>
Then status <expected>
Examples:
| method | path | expected |
| GET | /users/1 | 200 |
| GET | /users/99999 | 404 |
| DELETE | /users/1 | 204 |
JSON values in table columns:
Scenario Outline: Create user with <desc> returns <status>
Given path '/users'
And request <payload>
When method POST
Then status <status>
Examples:
| desc | payload | status |
| valid data | { "name": "Alice", "email": "a@b.com" } | 201 |
| missing email | { "name": "Alice" } | 400 |
| duplicate email| { "name": "Alice", "email": "existing@b.com" } | 409 |
Call with JSON array (better for complex payloads):
* def cases = read('classpath:data/user-validation-cases.json')
* call read('classpath:helpers/create-user-and-assert.feature') cases
Each element in the JSON array is one invocation of the feature. This avoids the readability problems of wide tables.
Each Examples row shows up as an independent test in the Karate HTML report, with the row values in the scenario name for easy identification.
// EXAMPLE
input-validation.feature
Feature: User registration validation
Background:
* url karate.properties['api.base.url']
Scenario Outline: Registration rejects <desc>
Given path '/register'
And request { email: '<email>', password: '<password>' }
When method POST
Then status 400
And match response.field == '<field>'
And match response.message contains '<hint>'
Examples:
| desc | email | password | field | hint |
| blank email | | Str0ng! | email | blank |
| invalid email | not-an-email | Str0ng! | email | valid |
| short password | a@b.com | abc | password | 8 characters |
| no uppercase | a@b.com | alllower1! | password | uppercase |// WHAT INTERVIEWERS LOOK FOR
Correct Scenario Outline + Examples syntax, the <placeholder> substitution pattern, and knowing when to switch to call-with-JSON-array for complex nested data. Each row producing a named independent test is a practical quality signal.
// COMMON PITFALL
Using a wide Examples: table with 8+ columns — this becomes unreadable in code review. Extract complex parametrised test cases to a JSON file in data/ and use the call-with-array pattern.