Why are you testing through the UI?

When asked what they think of when they hear automated testing. I would predict that many people (not all!), will think of a web browser being operated by a robot. Or a tool like Selenium or Cypress that you give instructions to and it navigates the web programmatically.

And while the former part of that statement is (partially) true. The latter is only referring to one type of automated testing and doesn’t cover the entire range of options that the term encompasses.

Testing at the UI level is a perfect option if we want to complete an end-to-end test from the perspective of a user. Confirm if the UI renders correctly under various conditions. Or check for visual inconsistencies without the effort of a human tester.

However, a problem becomes apparent when we want to run numerous tests to validate data, perform CRUD operations (CRUD stands for Create, Read, Update Delete). Or even basic operations like login/log out with many user accounts.

The Test Automation Pyramid

I’m sure most people have seen the test automation pyramid in one form or another already. There are various other representative images (including an ice cream cone). But the basic information is consistent throughout all the various depictions.

An automation strategy comprises three distinct layers. Unit tests, API and finally UI with the Unit tests covering the most of your testing and UI the least. This is because Unit tests are not only quicker to run and therefore cheaper. They can also run much earlier in development and have a greater potential to catch errors before reaching the UI.

And in the middle, you have the API (or sometimes referred to as the service layer). I don’t really want to go too in-depth on what an API is in this post. But essentially an API in a web application context enables the back-end of your application (the database for example) to communicate with the front end. There are a few types of API’s in use today with the most common ones being REST and the other being GraphQL.

The important thing to note here is that having one of these options doesn’t automatically mean you have an API. You also need an endpoint for users to consume with a program like Insomnia or Postman.

An endpoint is basically a way for your users to interact directly with your web application. An endpoint can also be secured with various options which would require you to include additional data with your request. Most likely an authentication token in the header, so the server knows who you are.

What can I do with an API?

The dominant use of an API’s and the advantage to testers is the ability to interact with the core functionality of an application through a series of commands using HTTP Verbs.

The most common ones being:

• POST which sends data.
• PUT which replaces data.
• GET which sends a request to retrieve data.
• DELETE which removes data.

A more complete list can be seen here.

So with the example of a web application in which one view in that application is a full list of registered users. Instead of writing a long Selenium script that loads up the UI. Logins in etc and retrieves the list of users. You only need to need to send a GET request to an API endpoint.

http://mywebapp.com/api/users

If you only want to retrieve a single record. Then all you need to do is include the ID in the request. Sometimes to retrieve a single record, the API endpoint accepts a string representation of the object. But the ID is the most common criteria. Make sure you read the documentation of your API to discover how it works.

http://mywebapp.com/api/users/1

The other critical thing to know about API’s is that the most common ones work with various data structures in a file format called JSON (which stands for JavaScript Object Notation).

So let’s say you want to create data for your web application. Again without using the UI. You would write a POST request containing:

{
    “Username”: “Bob”,
    “Email”: “test@example.com”,
    “Password”: 1234
}

API testing has many other use cases valuable to testers. From pushing a system to its limit, sending it data it doesn’t expect. And validating the data sent back from the server and ensuring it is in the expected data format.

What are the advantages of API testing?

The fact is UI tests are slow and prone to flakiness while testing with an API is faster and much more stable. And when the goal of testing using automation is to get test results faster. Running an extensive amount of UI level tests just doesn’t make much sense.

API’s allow you to interact directly with a server with no UI. They also allow testing to begin as soon as an early build is available. Meaning we can start running tests and performing operations to validate core functionality without complex forms and validation logic in place.

Testers still need to test the UI. But separating the two testing types into those that require a UI and those that don’t produces a more efficient test suite.

Have you got an example?

If you want to experiment with API testing for yourself. I have created the application Docket which allows you to register new users, create Todo objects, update those objects and delete them. All through a REST API.

There is also a set of test cases created with pytest here which you can download and learn from.

Let me know your thoughts about API testing in the comments below.

• Category: Software Testing