The attempts to understand API testing nuances have a serious potential to give unprepared readers headaches. In this article, we’ll try to explain everything you need to know about API testing in the simplest way possible.
Client-Server Architecture and HTTP Protocol
Let’s take a step back and start with the basics that allow QA specialists to work with APIs – client-server architecture and data transfer protocols.
A Few Words on Client-Server Architecture
A client-server architecture is a distributed application structure that partitions workloads between a service provider and its requester – a server and a client accordingly. It makes the application more secure, helps prevent access issues, and enables more users to run a program simultaneously.
Internet users have devices with different specifications and, thus, performance. Thanks to the client-server architecture, providers can guarantee equal (or at least close to equal) experience for all. Meanwhile, request processing, calculations, etc. are done on the provider’s end. Such an approach limits access to the source code and makes it much more difficult for a user to alter, making the system more secure.
There are three participants in this structure: client (user), server (hardware), and database (resources).
- A client is a local computer on the user’s side. It sends a request to a server to get certain information or perform certain system actions in response.
- A server is a powerful computer or specific hardware intended for dealing with specific system tasks – namely, running program codes.
- A database is an organized set of structured information usually stored virtually in a computer system.
Servers work in tandem with databases. Everything that happens in a system is recorded in a database. For example:
- A user forms a request.
- The request goes to a server.
- The server processes the request.
- The server sends data in return if necessary.
A Few Words on HTTP Protocol
All information on the web goes through the data transfer protocol known as HTTP (short for Hypertext Transfer Protocol). It is the foundation of every website. A computer uses HTTP to download a page from another computer somewhere on the Internet and show it to a user that requests the mentioned page at the moment. HTTP requests the necessary data (files, web pages, etc.) from a virtually remote system to display it on a local device.
Every HTTP message consists of three parts transmitted in the following order:
- Starting line – defines the type of outgoing request. In other words, it indicates the desired action to be performed on the identified resource. There are four main methods here: GET, POST, PUT, and DELETE.
- Headers – describe a message body, transfer parameters, etc. It is necessary to inform a server of what kind of data you are sending (multimedia data, JSON, etc). Otherwise, it won’t understand how to interact with the received data.
- Message body – the message itself separated from the headers by an empty field. It is not obligatory for operations that only request information and don’t need to share any incoming data.
There are five groups of HTML status codes:
- informational responses (100-199);
- success (200-299);
- redirection (300-399);
- client errors (400-499);
- server errors (500-599).
If an error is not matched and you don’t get a corresponding code displayed on the screen, you can use Chrome DevTools to get this information. Here, in addition to the status codes, you can find request methods, headers, and the rest of the request-related data.
Long story short, Chrome DevTools provides more information regarding requests and responses than you can access through the user interface. Besides, you can work with an API before the UI is developed. It allows catching numerous bugs in the early stages of software development and system design.
What Is an API?
An API stands for an application programming interface. It is an end-point created by a developer or a company that allows using any features of a program in a different place or another program.
In a way, it is a contract, an agreement between two parties that regulates the way they share and process data. A client agrees and undertakes they will address a server in a specific way. The server assures to return the data or process them in a way specified by the client.
For example, create a user, save it to a database, and return an identifier signaling about success or failure. That’s an internal API.
Using third-party APIs is also a common practice. For example, if you want to add a weather forecast on your website, you don’t need to develop an app for that. It would be enough to “attach” an app that already exists – if it allows doing so. An API will connect you to the weather functionality, becoming an intermediary between your website and the weather app.
Who Works with an API?
Anyone who interacts with a software system that uses an API can call it – directly or indirectly.
Direct usage of an API:
- A system calls internal features. For example, an application built on microservice architecture consists of a set of independent programs. Each of them has its API and uses it for function calls. For instance, delivery apps usually have two separate platforms – for customers and restaurants. These two apps communicate to exchange the data through API calls.
- System 1 calls for the methods of System 2. In other words, it is an integration between different systems. A good example is a widget (weather, tracking, etc.) on a website. Thus, your website will call for the tracking API and use the database to display the information.
- Using tools for interaction with an API. There are various tools (Postman, Swagger, Katalon, etc.) that will help you do this.
Indirect usage of an API:
- An end-user calls an API through a graphical interface. By clicking on buttons, a user initiates a particular action. A client forms a request and sends it to a server. You still deal with an API but do not access it directly.
REST API
Rumor has it that 90% of APIs in open access are REST APIs. REST is an architectural style for web services design. It was created to guide the development of the World Wide Web architecture. REST API is a set of functions and constraints defining how the architecture of the hypermedia systems should behave. In simple terms, REST defines the functions to which developers (or other systems) send requests and from which receive responses.
The interaction and data management process is entirely based on the HTTP protocol. Thanks to this, you can use REST API in probably any programming language. There is one downside, however: there is no hard-and-fast policy for REST API development. All resources on API are recommendations, not guidelines.
Benefits of API Testing
Just like any other type of testing, API checks allow us to find critical bugs before the system goes live. Apart from that, there are several specific particularities of API testing:
- A clear understanding of why an error occurs and what exactly causes it.
- QA engineers spend much less time preparing the test data.
- It becomes possible to run tests that involve big data sets with acceptable speed.
- The team can start testing at the early stages before the interface is completed.
Best API Testing Practices
In general, you can cover APIs with the following types of testing:
- functional – verification of the working ability of an API in general;
- usability –the convenience of calling an API for end-users;
- security – verification of the authentication type & data encryption;
- API performance testing – looking at the API’s behavior under different traffic conditions;
- documentation testing – integrity and clarity of API functions description;
- API automation – setting up the test automation process.
There are some tips that will help you make API testing easier and more efficient. Some of them are quite universal, so you can apply them in other types of manual and automated testing.
- Every test should be comprehensive and stand-alone. Otherwise, one failing test in this dependency will cause a chain reaction, making it complicated to figure out the problem.
- Make test cases comprehensive. It should be clear what function we are going to check.
- The parameter selection should be mentioned directly in the test. The sequence calls should be well-planned and completed. By looking at the test case, a QA engineer should understand what parameters we are going to use, even if this specialist is new to the project.
- Set the priority of API calls. Software features have different priorities, so make sure to specify this to plan the testing activities correctly.
- Be especially careful with functions that delete, modify, or change something. The reason is simple: you may be not the only one to use this data and features.
Last but not least, keep your tests in order. Group them based on the categories where these tests belong. For example, if we are working with the functionality of user creation, all the tests should be related to this functionality. Don’t add order placement checks or something else to this scope.
API Testing Challenges
Now, it’s time for a short overview of common mistakes and difficulties that pop up during the testing process. Here’s our top-5 rating.
There are a variety of combinations and parameters to use for testing a particular end-point.Choosing the right test design techniques is a solution.
The absence of a graphical interface can cause difficulties. Though it can be an advantage, it may also be complicated to test functionality without an interface, especially if you are new to API testing.
Data validation and verification can proceed differently in different systems. A server receiving data may not be able to read and process it due to the used type of data.
It is obligatory to check the processing of exceptions. QA specialists often forget about this one. To work with the exceptions you should know the rules of processing such data and requests. For example, try sending ‘null’ in a field supposed to feature data or sending a numeral instead of a string value.
Software testers need to have partial knowledge of programming. This one is controversial. If you know the basic understanding of client-server architecture, it is enough for API testing. On the other hand, even programming knowledge will boost your skills.
API Testing Tools
There are a variety of tools for working with API. Some of the most widely used are:
- Postman – an API platform that is used not only for testing but building and using APIs as well.
- REST-assured – a tool for testing and validating REST services that promises to make this process as simple as possible.
- JMeter – an open source software written in Java and originally designed for testing web apps.
- SOAP UI – a tool available as an open source or commercial solution that also promises to create, manage, and execute tests easily.
- Tricentis – a codeless platform for automating end-to-end tests, fully driven by AI technology.
- Apigee – an API management and testing platform that is now a part of the Google Cloud ecosystem.
- Katalon – a multi-functional low-code test automation platform that offers API testing among the other capabilities.
As the experience shows, the greatest share of automation tasks falls on Postman API testing. Nevertheless, getting familiar with a variety of platforms is always a benefit for a QA specialist.
To Sum Up
API testing can seem pretty difficult, but with the right resources at your disposal, you’ll figure out the secrets quickly. Good luck with your studying and practice 😉