How does Testfully verify your API automatically?

How does Testfully verify your API automatically?



Introduction


Validation (sometimes called assertion or checks) is one of the core concepts of any testing tool. When it comes to validation of your API, Testfully verifies behaviour of each step within tests independently. Moreover, we support validation for the following aspects of APIs:

  • Response Code
  • Response Time
  • Response Body
  • Response Headers



1. Response Code


This optional validator is one you should probably set for all of the steps of a test case. Using it you can set what you expect as the “HTTP Response Code”. Testfully makes sure that the actual response code is exactly what you have defined as the expected one otherwise the test fails.

The example below shows a test case with a single “Response Code” validator. Here we expect to receive the “200 OK” code in response.

Set response code validation for your API test



2. Response Time


This optional validator is suitable for measuring the performance of your API and making sure that users get the response within the expected time frame. To configure this validator, simply provide the expected response time in milliseconds. Testfully compares the actual response time with the expected one and fails if the actual response time is greater than the expected one.

The example below shows how response time is configured for a test case to be 1200 milliseconds.

Set response time validation for your API test



3. Response Body


This optional validator is suitable to match the response against a provided JSON object. Testfully tries to match the provided fields in “Response Body” against the actual values in response and the test fails if at least one of the defined fields in “Response Body” section is missing or has a value that does not match the provided value.

The example below shows a valid JSON object in “Response Body” field. We’re expecting that:

  1. Response from API comes with a field called “success” and the field MSUT have “true” as value.
  2. Response from API comes with a field called “workspaceId” and the field value MUST be “928031722”.

Validate response body of a request

What would happen if API responds with the mentioned fields and some other fields, you might wondering? Well, Testfully simply ignores those fields and assumes those fields don’t exist at all.

A couple of things about “Response Body” you should probably know:

  1. The test fails as soon as one of the response body validations fail.
  2. Response Body only supports valid JSON data.
  3. Nesting is fully supported, you can even include arrays.



4. Response Headers


Response Headers validator is identical to Response Body, albeit it does the validation against the Response Headers.

The example below shows how we define “Content-Type” header field and corresponding “application/json” value as the expected header in response. This example contains only two headers but you can add as many as headers you want.

Validate response headers of a request

A couple of things about “Response Headers” you should probably know:

  1. The test fails as soon as one of the response header validations fail.
  2. Response Header only supports valid JSON data.
  3. Nesting is not supported.
comments powered by Disqus

Recent Articles

blog-image
7 HTTP methods and how to use them

HTTP protocol works by clients sending requests to the servers and servers responding to the requests. We do CRUD operations (Create, Read, Update, Delete) by sending HTTP requests with different HTTP methods, sometimes called HTTP verbs.



blog-image
Introduction to API Blueprint

API blueprint is a powerful high-level API design language for web APIs. In this article, we want to dive deeper into it and learn more about how it works, the differences between API blueprint and Swagger, and what makes it unique that leads to its extensive use. But before we dig into API Blueprint, we must ensure a solid base of information about the “API first approach” concepts.

blog-image
False positive & false negative in software testing

Exports in automated software testing have borrowed false positive and false negative terms from the medical examination field. In the medical field, the purpose of a test is to determine whether the patient has a particular medical condition or not. As far as software testing is concerned, a false positive indicates a bug when there is none. Conversely, a false negative indicates no bug when there is one.