Handling errors
Sometimes your API will fail, either during development or in a live environment. Capter can help you catch it before a customer does!
Even if a request fails, Capter will continue with the rest of the steps unless you tell it not to. This is because sometimes you want the API to return an error, and assert on that โ like a failed login attemt or bad user input.
#
Handling unexpected errorsThe way to trigger a real error is to have an assertion fail:
In the above example we expect the health endpoint to be secure, and return 400 if no authorization token is sent with the request. Capter will show what assertions failed, together with both the expected and the actual value you're asserting on.
In the above example you can see that we are getting:
This is because the endpoint is not returning 400, it's returning an unexpected 200.
#
Handling expected errorsYou can make requests that are designed fail, and then assert on the error you get back. This will be treated as a successful step:
When we get an error back, we do our best to populate status
, body
, headers
and duration
so you can assert on those just like on a successful request.
#
LogsTo make it easier to debug, Capter will log failed workflows to .capter/logs
. These logs includes the requests and responses. If the output from the CLI doesn't give you all the info you need, take a look at these logs!