Assertions

To make sure that you API is working correctly, you probably want to add some assertions to your workflows – and Capter makes that super easy!

You write the assertions in plain English, and Capter parses them in to actual assertions.

Asserting on a response

You add assertion at the end of each step:

# .capter/products.yml

name: products

steps:

- name: fetch all products

url: https://fake-api.capter.io/api/products

assertions:

- !expect status to_equal 200

- !expect body to_be_array

In the above example we assert that the status equals 200 and that the body we get back is an array.

What you can assert on

There are four things you can assert on:

• status - the HTTP status you get back
• body - the response body
• headers - the response headers
• duration - how long it took to get a response back

Testing the opposite using the !! operator

You can invert a test by adding an extra ! at the start of the assertion string:

- !!expect status to_equal 500

The above test will fail if the status equals 500. This is equal to the .not extension you see in many other test frameworks.

Composing an assertion

Sometimes you want to assert that a response matches something in a previous response, for example:

• Create a product
  • Assert that we get a product with an id back
• Use the id from the create response to fetch the product
  • Assert that the id of that user matches the id in the create step

In a Capter workflow, that would look something like this:

# ./capter/product-crud.yml

name: product crud

steps:

- name: create product

id: create

url: POST https://fake-api.capter.io/products

assertions:

- !expect body.id to_exist

- name: fetch product

url: https://product-api.com/products/${{ create.response.body.id }}

assertions:

- !expect body.id to_equal ${{ create.response.body.id }}

As you can see on the highlighted line above, we can use values from the previous step in our assertions!

Available assertions

Have a look at the workflow reference page.