Two different flavours of feature files

Format 1 - Scenario outline with example table

Given I have a valid auth token
When I submit a POST request to create a user with the following details:
| first_name  | last_name    | email    | mobile_phone | date_of_birth | password    | username    |
| <first_name>| <last_name>  | <email>  | <mobile_phone>| <date_of_birth> | <password>  | <username>  |
Then the response status code should be <status_code>

Examples:
| first_name | last_name| email                 | mobile_phone | date_of_birth | password    | username    | status_code |
| John       | Doe      | johndoe@example.com   | 1234567890   | 1990-01-01    | password123 | johndoe123  | 201         |
| Jane       | Smith    | janesmith@example.com | 0987654321   | 1985-02-14    | password456 | janesmith12 | 201         |

This format gives a higher level of abstraction where the same scenario is run multiple times with different sets of data. Yes data including the expected result as well. 

This format is useful when you don't want to repeat the same scenario. Also when you have a simpler payload.

Format 2 - Single Scenario with Given\When\Then steps

Feature: Create User API

  Scenario: Create User Successfully
    Given the user payload is:
      | first_name    | John                 |
      | last_name     | Doe                  |
      | email         | john.doe@example.com |
      | mobile_phone  | 1234567890           |
      | date_of_birth | 1990-01-01           |
      | password      | password             |
      | username      | johndoe              |
    When I send a {method} request to {path}
    Then the response status code should be 201
    |method   | path         | status_code |
    | POST    |/users/create"|201          |

This gives more detailed description of the scenario. Each @Given, @When, @Then step is elaborated with relevant data.

In this case you may be having more specific scenarios and conditions.

Using feature files for API test autimation - 2

 Feature file

Similar to the last post, I'm usinng RestAssured for API test automation. Cucumber is used for mapping the feature scenarios. Also extending AbstractTestNGCucmberTests to run the test suite.

Difference is the way the payload is handled. Instead of reading the payload from exmaple tables, I am loading it from a json file.

This way it gives me more flexibility in managing test data/payloads.

I am still using exmaple tables to read other paramaters via <> tags in my featuer file .

Feature: Create User API

  Scenario Outline: Create User Successfully
    Given the user payload file is <data_file>
    When I send a <method> request to <path>
    Then the response status code should be <status_code>

    Examples:
    | data_file                             | method | path                  | status_code |
    |/test/java/resources/user_details.json | POST   | /user_accounts/create | 201         |

Payload file

{
  "first_name": "John",
  "last_name": "Doe",
  "email": "john.doe@example.com",
  "mobile_phone": "1234567890",
  "date_of_birth": "1990-01-01",
  "password": "p@ssword_1",
  "username": "johndoe"
}

CreateUserStep.java

public class CreateUserSteps{
    private RequestSpecification requestSpec;
    private Response response;
    private String requestBody;

    @Given("the user payload file is {string}")
    public void the_user_payload_file_is(String filePath) {
        requestBody = TestDataUtil.getJsonRequestString(filePath);
    }

    @When("I send a {string} request to {string}")
    public void i_send_a_request_to(String method, String path) {
        response = requestSpec.contentType(ContentType.JSON)
                .body(requestBody)
                .when()
                .request(method, path);
    }

    @Then("the response status code should be {int}")
    public void the_response_status_code_should_be(int statusCode) {
        response.then().statusCode(statusCode);
    }
}