Skip to main content

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.