# Then Steps ### Asserting for HTTP Status Codes #### #### Then response status code should be `{expected status code}` If we want to test if the response to the request that we did is having the expected status code. Let say we are expecting a successful request having a 200 status code. ``` Scenario: Getting user information Given that a endpoint is up at mydomain.com Given I set Content-Type header to application/json Given I set DocId header to 3001 When I GET /users/info Then response status code should be 200 ``` If the status code is not as expected this will generate a failed test. #### #### Then response status code should not be `{expected status code}` This is the same as above but a negative test instead. ``` Scenario: Getting user information Given that a endpoint is up at mydomain.com Given I set Content-Type header to application/json Given I set DocId header to 3001 When I GET /users/info Then response status code should not be 404 ``` ### ### Validating HTTP Headers #### #### Then response header `{expected HTTP Header}` should exist This will assert if the expected HTTP Header exist from the response. ``` Scenario: Getting user information Given that a endpoint is up at mydomain.com Given I set Content-Type header to application/json Given I set DocId header to 3001 When I GET /users/info Then response status code should not be 200 Then response header "Server" should exist ``` If the header does not exists then it will failed the test, and will have a message Expected header (Server) is missing. #### #### Then response header `{expected HTTP Header}` should not exist This is the negative test of the previous HTTP Header test. If the expected header exists then the test will failed. ``` Scenario: Getting user information Given that a endpoint is up at mydomain.com Given I set Content-Type header to application/json Given I set DocId header to 3001 When I GET /users/info Then response status code should not be 200 Then response header "Server" should not exist ``` #### #### Then response header `{expected HTTP Header}` should be `{expected HTTP Header value}` If we want to test not just the existence of the header, we can also assert if the value of the response header is the same as what we are expecting. ``` Scenario: Getting user information Given that a endpoint is up at mydomain.com Given I set Content-Type header to application/json Given I set DocId header to 3001 When I GET /users/info Then response status code should not be 200 Then response header "Server" should be "Autokin Server 2.1" ``` #### #### Then response header `{expected HTTP Header}` should not be `{expected HTTP Header value}`' This step is the reverse or negative test for the HTTP Header and value check. ``` Scenario: Getting user information Given that a endpoint is up at mydomain.com Given I set Content-Type header to application/json Given I set DocId header to 3001 When I GET /users/info Then response status code should not be 200 Then response header "Server" should not be "Autokin Server" ``` ### ### Verifying Response Body #### #### Then response body should be valid json This is a simple assert step to validate if the response body is in JSON format. ``` Scenario: Getting user information Given that a endpoint is up at mydomain.com Given I set Content-Type header to application/json Given I set DocId header to 3001 When I GET /users/info Then response body should be valid json ``` #### #### Then response body should be json data of If we want to assert the JSON body as a whole and compare to what we expect we can use this step. ``` Scenario: Getting user information Given that a endpoint is up at mydomain.com Given I set Content-Type header to application/json Given I set DocId header to 3001 When I GET /users/info Then response body should be json data of """ `{ "id": 3001, "name": "Juan Pedro", "country": "PH" }` """ ``` This step will compare each of the JSON property and value as well. If the structure or the value does not match to the response then it will fail the test. ### ### Asserting for JSON Paths and Value The following steps will be used to assert paths and values of the JSON body response. For our examples, we will use this response body ``` `{ "id": 3001, "name": "Juan Pedro", "country": "PH", "city": null, "tasks": [ `{ "tid": 1, "name": "Task 1" }`, `{ "tid": 2, "name": "Task 2" }` ] }` ``` #### #### Then I expect that path `{path}` from body has value of `{expected value}` Let us assert for a specific path with expected value, for example, in the above reponse we want to check for * path for id to have the value 3001 * and the path for country to have the expected value of PH ``` Scenario: Getting user information Given that a endpoint is up at mydomain.com Given I set Content-Type header to application/json Given I set DocId header to 3001 When I GET /users/info Then I expect that path "$.id" from body has value of 3001 Then I expect that path "$.country" from body has value of "PH" ``` #### #### Then I expect that path `{path}` from body has null value Let us assert for a specific path with expected null value, for example, in the above reponse we want to check path for city which has a null value. ``` Scenario: Getting user information Given that a endpoint is up at mydomain.com Given I set Content-Type header to application/json Given I set DocId header to 3001 When I GET /users/info Then I expect that path "$.city" from body has null value ``` #### #### Then response body should have path `{expected JSON path}` This simple step is just to assert if the expected path exists. ``` Scenario: Getting user information Given that a endpoint is up at mydomain.com Given I set Content-Type header to application/json Given I set DocId header to 3001 When I GET /users/info Then response body should have path "$.id" Then response body should have path "$.tasks[0].tid" Then response body should have path "$.tasks[1].name" ``` #### Then I expect that from path of`{JSON Path}` contains `{expected value}` Assert if one of the values that can be retrieve using the JSON path contains part of the expected value. If the path resolves to an object, it will be converted to string and will be use as part of the comparison. ``` Scenario: Getting user information Given that a endpoint is up at mydomain.com Given I set Content-Type header to application/json Given I set DocId header to 3001 When I GET /users/info Then I keep the value of header "Server" as "serverName" Then I expect that from path of "$.data..role" contains "Autokin Admin" ``` #### Then I expect that from path of`{JSON Path}` not contains `{expected value}` Assert if none of the values contains the expected value. This is the negative assertion of the previous Then. ``` Scenario: Getting user information Given that a endpoint is up at mydomain.com Given I set Content-Type header to application/json Given I set DocId header to 3001 When I GET /users/info Then I keep the value of header "Server" as "serverName" Then I expect that from path of "$.data..role" not contains "Autokin Admin" ``` For more information, see , and Autokin is using for JSON Path processing. ### ### Storing Response Values To chain scenarios, we need to keep some of the value that was part of the repponse from previous scenarios, to do this we can use the following steps. #### #### Then I keep the value of body path `{JSON body path}` as `{store name}` Let us have an example to store a value form the response body using a specific JSON path. ``` Scenario: Getting user information Given that a endpoint is up at mydomain.com Given I set Content-Type header to application/json Given I set DocId header to 3001 When I GET /users/info Then Then I keep the value of body path "$.id" as "userId" ``` Now, we can use userId in some of the steps to pass as value of the header or parameters. #### #### Then I keep the value of header `{name}` as `{store name}` ``` Scenario: Getting user information Given that a endpoint is up at mydomain.com Given I set Content-Type header to application/json Given I set DocId header to 3001 When I GET /users/info Then I keep the value of header "Server" as "serverName" ``` #### #### Then I expect that the stored value in `{store name}` is `{expected value}` We can also assert if the value stored is the same as what we are expecting. ``` Scenario: Getting user information Given that a endpoint is up at mydomain.com Given I set Content-Type header to application/json Given I set DocId header to 3001 When I GET /users/info Then I keep the value of header "Server" as "serverName" Then I expect that the stored value in "serverName" is "Autokin Server" ``` #### Then I save data from path`{JSON Path}` that contains `{expected value}` to file `{file path}` Allow to capture filtered data and save into a local file. ``` Scenario: Getting user information Given that a endpoint is up at mydomain.com Given I set Content-Type header to application/json Given I set DocId header to 3001 When I GET /users/info Then I keep the value of header "Server" as "serverName" Then I expect that from path of "$.data..role" contains "Autokin Admin" Then I save data from path "$.data..role" that contains "Admin" to file "admin.json" ``` --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://autokin.gitbook.io/docs/autokin-rest/then-steps.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.