Too much scenario combination? Move to Scenario Outline

Irkham
Kitalulus Engineering
3 min readJun 23, 2023

When doing testing, most of time we found when the same test is performed multiple times with a different combination of values. This was a perfect time to implement Test Scenario Outline.

Why ? Lets doing comparisons

Test case explanation :

Its graphql testing using karate
as a user i’m able to login with email and password
assert status code

curl example :

curl — location — request POST ‘{{baseUrl}}' \
— header ‘content-type: application/json’ \
— data-raw ‘{“operationName”:”login”,”variables”:{“user”:{“username”:”{{email}}”,”password”:”{{password}}"}},”query”:”mutation login($user: UserLoginInput!) {\n login(user: $user) {\n isSuccess\n data\n warning\n error\n __typename\n }\n}\n”}’

project directory

project
- | loginUser.graphql
- | variables.json
- | invalid.json
- | headers.json
- | login.feature

#1 create loginUser.graphql

mutation LoginUser($user: UserLoginInput!) {
login(user: $user) {
isSuccess
data
__typename
}
}

#2 create variable.json

{
"user": {
"username": "irkham@email.com",
"password": "password"
}
}

#3 create invalid.json

{
"user": {
"username": "irkham@email.com",
"password": "wrongpassword"
}
}

#4 create headers.json

{
"Content-Type":"application/json"
}

Now we create test scenario using common ways , login.feature

Feature: Login User

Background:
* url baseUrl
* def headers = read('project/headers.json')
* def query = read('project/loginUser.graphql')
* def variables = read('project/variables.json')

Scenario: user login with valid data
Given headers headers
When request { query: '#(query)', variables: '#(variables)' }
And method post
Then status 200
Scenario: user login with invalid data
Given headers headers
* def variables = read('project/invalid.json')
When request { query: '#(query)', variables: '#(variables)' }
And method post
Then status 403

or we can using the other ways, with changing login.feature and variable.json

change variable.json

{
"user": {
"username": "#(email)",
"password": "#(password)"
}
}

change test file, login.feature

Feature: Login User  Background:
* url baseUrl
* def headers = read('project/headers.json')
* def query = read('project/loginUser.graphql')
* def variables = read('project/variables.json')
Scenario: user login with valid data
Given headers headers
* set variables.user.username = 'irkham@email.com'
* set variables.user.password = 'password'
When request { query: '#(query)', variables: '#(variables)' }
And method post
Then status 200
Scenario: user login with invalid data
Given headers headers
* set variables.user.username = 'irkham@email.com'
* set variables.user.password = 'wrongpassword'
When request { query: '#(query)', variables: '#(variables)' }
And method post
Then status 403

Now lets try to implement Test Scenario Outline on this feature

using this variable.json

{
"user": {
"username": "#(email)",
"password": "#(password)"
}
}

change test file login.feature

Feature: Login UserBackground:
* url baseUrl
* def headers = read('project/headers.json')
* def query = read('project/loginUser.graphql')
* def variables = read('project/variables.json')
Scenario Outline: Login with <case>
* set variables.user.username = '<email>'
* set variables.user.password = '<password>'
Given headers headers
When request { query: '#(query)', variables: '#(variables)' }
And method post
Then status <status>
Examples:
| email | password | status | case |
| irkham@email.com | password | 200 | valid data |
| irkham@email.com | invalid | 403 | wrong password |
| xxxxxx@xxxxx.com | password | 403 | wrong email |
| xxxxxx@xxxxx.com | invalid | 403 | wrong email&password |
| | password | 403 | blank email |
| irkham@email.com | | 403 | blank password |

A Scenario Outline must contain one or more Examples (or Scenarios) section(s). Its steps are interpreted as a template which is never directly run. Instead, the Scenario Outline is run once for each row in the Examples section beneath it (not counting the first header row). The steps can use <> delimited parameters that reference headers in the examples table. For the test result will be like this.

result.html

Conclusion

Scenario Outline have more benefits on top of a Scenario if properly coded. Scenario and Scenario Outline serve different purposes, they are written the same way but Scenario Outline takes user data in the form of Example table and run the scenario. So rather than duplicating same scenario with different data, one can write one Scenario Outline and write all data in Example table. One can make the code as generic as possible to enhance the step definition reuse and follow coding practices. It shown how scenarios can be made generic in nature. And also reduce effort in writing and maintaining these scenarios.

--

--