API stands for Application Programming Interface. This interface allows developers to build an application using ready-made blocks. For example, your website is supposed to show the user the railway or airplane timetable, exchange rates or weather forecast, etc. You will not need to reinvent the wheel, you just need to find a suitable API for your purposes and take data from third-party web applications using their API. For example, Github provides an API that other developers can use. How they will use it depends on the possibilities of the API.
To illustrate, let’s paste the link below into the address bar of your browser:
The browser will make a GET request and give you a list of job offers for python language specialists in New York. By changing the value of the description or location parameter, you can change the search criteria for vacancies.
This is a simple example of working with the Github API.
What Is API Testing?
API Testing involves testing an API. It differs from GUI Testing and is mainly focused on the business logic of the software architecture. In API testing, you use software to send calls to the API, receive output, and record the system’s response. This testing does not focus on the interface of the application. In the example above, the browser was acting as the software making the request to the Github API. In the browser, we displayed the received data. API testing differs from other types of software testing as a graphical interface is not available and often you need to set up an initial environment that calls the API with the required set of parameters and then finally validates the test result.
Differences Between Unit and API Testing
Sometimes beginners confuse unit and API testing, even though each of them “lives” at its own level (automation and test pyramid). Below you will find the main differences between them.
Performed by developers
Tests isolated modules
The developer has access to the source code
UI testing can also be involved
Tests only basic functionality
Usually run before building a build
Performed by testers
Tests End-To-End (E2E) Style Functionality
No access to source code
Only API functions are tested
A wider range of functionality
Run after build creation
Types of Testing That Can Be Performed Within the Testing API
Usability testing: This testing checks if the API is functional and user-friendly. How well does the API integrate with another platform?
Security testing: this testing includes the type of authentication required and sensitive data encryption.
Documentation testing: The testing team must ensure that the documentation is comprehensive and provides sufficient information to interact with the API.
But the main type of testing will be functional testing, using all the “black box testing” methods, where the tested API will be the “black box”.
API Response Types
Any data type (in the previous example, the response was data in JSON format)
Response status (for example, a successful or unsuccessful request to the API was made)
Calling another API function (for example, after deleting a record in the database by calling the API function, another API function that updates the database can be automatically called)
The response data is not structured correctly or is of an inappropriate type (for example, it does not correspond to the expected format (JSON or XML))
Absence or duplication of functionality. For example, unused flags.
Questions of reliability. Difficulty connecting and getting a response from the API
Problems of multithreading
Problems with performance. API response time is very slow
Simple API Testing Tips
Test scenarios should be grouped into test categories. It is desirable to have a description (declaration) of the called APIs at the top of each test.
The choice of parameters must be explicitly specified in the test script itself
It is desirable to have priorities of calls to API functions
The sequence of API calls must be well planned
Particular attention should be paid to handling one-off call functions (for example, Delete).
Each test case should be as independent as possible
Avoid connected tests
To provide more test coverage, create test cases for all possible API input combinations. Use a data-driven approach. In RESTful web services, the input is usually JSON, and in some cases, the missing value of a specific key is treated differently (null, empty). To avoid these ambiguous test scenarios, it is strongly recommended that you use a subset of the input data models.
Do not forget to create both positive and negative test scenarios
Simple Examples of Tests
Do you want to join us?
Leave an application and get a free consultation from our manager.
Help in choosing a direction
Additional materials for the start
Make sure the API receives input and returns the expected output as specified in the requirement.
Verify that the response status code is returned as specified in the request, whether it returns a 2xx code or an error code.
Check API requests with the minimum required fields and with the maximum number of fields.
Make sure the API returns an appropriate response when the expected result does not exist.
Check the validation of all required and optional request parameters.
Check API behavior with different authorization levels.
The API consists of a group of classes, functions, or procedures that represent the business logic layer. If the API is not properly tested, it can cause problems not only in the API application but also in the calling application. That is why API testing is necessary for software development.