Testing REST APIs

For many companies, it is crucial to build and maintain APIs for the Web. Building robust APIs that will be maintained and improved over time comes with a lot of challenges. This article will go through things to remember when testing REST APIs and show you what makes Humlix different from other testing tools available. For a more basic introduction to creating a REST API, you can check out the article Create and test RESTful APIs.

If you haven’t heard about Humlix before, it is a tool to help out when building and testing RESTful APIs. It can automatically generate tests to discover errors in API endpoints.

REST

REST (Representational State Transfer) is a software architecture style relying on stateless communication, often using the HTTP protocol. REST APIs (also referred to as RESTful APIs) make it possible for systems implemented with different technologies to collaborate and understand each other.

Specifying a contract

Using, e.g., OpenAPI, it is possible to specify the API before writing code and let teams develop in parallel by implementing code according to the contract. It also makes it easier for tools to understand how the API works and allows them to display the API documentation or generate code based on the specification.

An OpenAPI specification states, e.g., HTTP status code, payload, headers, and makes it possible to use tools like Humlix to understand the API and use that as a base for generating tests.

Ways of testing

Different ways of testing a REST API is to cover:

Contract testing or schema validation
- Use tooling to verify that the API corresponds with a given OpenAPI specification.
Basic positive testing
- E.g., use code or tooling to test happy paths
Testing with valid and invalid input
- Verify that the API handles valid and invalid input both for query and path parameters and for the payload correctly

Traditionally REST APIs are often tested using positive tests. Developers write tests for the API's happy paths and possibly extending it with some edge cases that they think of quickly.

Tooling

Today's tooling for testing REST APIs often lets the user create test cases by manually writing some test code, e.g., using Javascript or doing calls given example data. Using tooling like that makes it easy to reach a basic level of testing quickly.

Humlix test data generation logic makes it possible to discover edge cases that would be hard to think of for a developer writing all the tests manually. Make sure to look at this article describing how Humlix was used to discover bugs in GitLab CE. Humlix unique way of understanding an OpenAPI specification combined with Property-based testing makes it easy to find otherwise hard to find bugs.

Developer experience (DX)

Remember to walk through the experience for developers that will use the API. How is the API documented? Is it easy to figure out how to use the API? Provide code examples showing how to authenticate and start using the API.

DX is, generally speaking, how developers feel while using an API. With good DX, developers have a better chance of making quality products than using an API with horrible DX. If your API is public, DX will be one selling point compared to your competitors.