API vs Unit Testing

What Is an API?

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:

• https://jobs.github.com/positions.json?description=python&location=new+york

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.

Unit testing

• 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

API testing

• 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

1. Usability testing: This testing checks if the API is functional and user-friendly. How well does the API integrate with another platform?
2. Security testing: this testing includes the type of authentication required and sensitive data encryption.
3. 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

1. Any data type (in the previous example, the response was data in JSON format)
2. Response status (for example, a successful or unsuccessful request to the API was made)
3. 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)

Types of Errors That API Testing Can Detect

1. Inability of the API to correctly handle errors
2. Incorrect error messages (warnings)
3. Incorrect handling of valid argument values
4. 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))
5. Absence or duplication of functionality. For example, unused flags.
6. Questions of reliability. Difficulty connecting and getting a response from the API
7. Security issues
8. Problems of multithreading
9. Problems with performance. API response time is very slow

Simple API Testing Tips

1. 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.
2. The choice of parameters must be explicitly specified in the test script itself
3. It is desirable to have priorities of calls to API functions
4. The sequence of API calls must be well planned
5. Particular attention should be paid to handling one-off call functions (for example, Delete).
6. Each test case should be as independent as possible
7. Avoid connected tests
8. 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.
9. Do not forget to create both positive and negative test scenarios

Simple Examples of Tests

Positive test

1. Make sure the API receives input and returns the expected output as specified in the requirement.
2. Verify that the response status code is returned as specified in the request, whether it returns a 2xx code or an error code.
3. Check API requests with the minimum required fields and with the maximum number of fields.

Negative test

1. Make sure the API returns an appropriate response when the expected result does not exist.
2. Check the validation of all required and optional request parameters.
3. Check API behavior with different authorization levels.

Conclusion

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.