Too much scenario combination? Move to Scenario Outline
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 200Scenario: 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 200Scenario: 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.
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.