10 tips for API testing for beginners (SOAP & REST)
API (Application Programming Interface) testing is a type of software testing that performs tests directly in the API. This is part of the integration test to determine if the APIs meet the tester’s expectations for functionality, reliability, performance, and security. Unlike UI testing, API testing is done with the level of data returned.
1. Tip for API testing
There are two types of web services for APIs, including SOAP and REST. SOAP (Simple Object Access Protocol) is a standard protocol defined by the W3C standards for sending and receiving web service requests and responses. REST (REpresentational State Transfer) is a web standards-based architecture that uses HTTP. Unlike SOAP-based web services, there is no official standard for RESTful Web API.
Here are 10 basic tips you need to know to test the API:
1.1. Understand the API requirements
Before testing your API, you need to answer these questions to understand the API requirements:
- What is the purpose of the API?
Knowing the purpose of the API will lay a solid foundation for you to prepare your test data for input and output. This step also helps you to determine the viewpoint test. For example, for some APIs, you will test with data from the database and for others, it’s better to test data integrity with other APIs.
- What is the application workflow? and where is the API used in that stream?
In general, an application’s API is used to manipulate its data. They are used to retrieve, create and update application data. Knowing the purpose of the API will lay a solid foundation for you to prepare your test data for input and output. This step also helps you determine the test method.
For example, the “Create User” API output will be the input of the “Get User” API. API output “Get User” can use API “Update User”, …
1.2. Common API response status
The most common API output you need to test in your test API is the response status.
Test whether the response status is equal to 200 or not to determine whether the test API has passed or failed for the new API testers. This is not a false test. However, it does not reflect all of the API test scripts.
All API response statuses are separated into five groups (or categories) within an international standard. The first digit of the response code identifies the response group. The last two digits represent a category in the group.
There are five groups as follows:
- 1xx (Informational): The request is received and continues to be processed
- 2xx (Successful): Resquest is received, understood and processed
- 3xx (Redirect): Additional action is required to complete the request
- 4xx (Client error): Request contains a wrong syntax or cannot be executed
- 5xx (Server error): The server did not make a valid request
However, the actual API status response is specified by the developer team who built the API. So, as a tester, you need to test:
- Response code according to international standards
- Response code is specified on request.
1.3. Focus on small APIs
In a test project, there are always some simple APIs with only one or two inputs such as login API, API to get tokens, API health check … However, these APIs are necessary and considered as a gateway. to use the API. Focusing on these APIs before other APIs will ensure that the servers, environment, and API authentication work properly.
You should also avoid testing more than one API in case of testing. It is a headache if an error occurs, you will have to find the data flow generated by the API in the tested order. Keep your test case as simple as possible. There are some cases where you need to call a series of APIs to get a test flow from start to finish. However, these tasks will appear after all the APIs have been individually tested.
1.4. Management of endpoint APIs
A test project may have several or even hundreds of APIs to test. We recommend that you organize them into sections for better test management. An extra step is needed, but it will help you to create scenerio tests with high coverage and integration. Get the JIRA API, for example:
APIs of the same type share some information such as resources, paths, etc. Organizing your tests with the same structure will make your tests reusable and expandable with the integrated stream.
1.5. Utilize automation to test API
Take advantage of automation to test your API as much and as soon as possible. Here are some of the significant benefits of automation of test APIs:
- Test data and execution history can be saved along with API endpoints. This makes testcase easier to run again for later tests.
- The testcase API should be stable and change carefully. An API reflects a system’s business. Every change in the API needs a clear request; So the tester can always notice any changes and adjust them on time.
- Running tests is much faster than UI testing the web
- API testing is considered a black box test in which the user sends input and receives output for testing. Automation with a data-based approach – that is, applying different data sets in the same test scenario – can help increase the scope of API testing.
- Import and export data in specific models or models so you can only create test scripts once. These test scripts can also be reused throughout the test project.
- API tests can be performed at an early stage in the software development life cycle. An automation approach with mock techniques can help test the API and its integration before the actual API is developed. Therefore, the level of dependency in the team is reduced.
1.6. Choose an appropriate automation tool
One more step to take advantage of automation of test API is to choose the most appropriate tool. Here are some criteria that you should consider when choosing test automation API tool:
- Does the tool support importing API / Web services from WSDL, Swagger, WADL or some other method? This is an optional feature. However, it will take time if you have hundreds of APIs to test.
- Does the tool support data-based testing methods? This is also an optional feature. However, your test scope will increase significantly if the tool has this function.
- Last but not least, besides testing API, do you need to perform other types of tests, such as WebUI or data source? API testing is done in the business between database and user interface. It is normal for all of these sections to be tested. A tool that supports all types of tests would be an ideal choice for test objects.
Reference: 5 automation testing tool for API
1.7. Choose the appropriate test method
While the response status indicates the status of the request, the response body is the content that the API returns with the specified input. API response varies from data type to size. Responses can be in the form of text, JSON, XML or other types. They can be a few simple (even empty) word strings or hundreds of JSON / XML files. Therefore, it is necessary to choose an appropriate test method for a given API.
In general, there are some basic methods for testing API responses:
- Compare the entire response content with the expected info
This method is suitable for a static content response. Dynamic information such as date time, ID increase, etc. will cause testcase errors.
- Compare each attribute value of the response
For responses in JSON or XML format, it’s easy to get the value of a certain key or attribute. Therefore, this method is useful when testing dynamic content or individual values instead of the entire content.
- Comparison with regex (regular expression)
In addition to testing individual attribute values, this method is used to test response data with a specific pattern to handle complex dynamic data.
Each test method has its pros and cons and there is no one size option that fits all. You need to choose the solution that best suits your test project.
1.8. Create positive and negative cases
API testing requires both positivev and negative case tests to ensure the API works correctly. Because the test API is considered a black box test, both types of tests are controlled by input and output data. There are a few suggestions for creating test scripts:
- Positive case
- Test that the API receives the input and returns the output as expected according to the requirement.
- Test that the response status is returned as in the requirement, regardless of whether it returns a 2xx or an error code.
- Specify input with minimum required fields and with maximum fields.
- Negative case
- Test that the API returns the expected response with non-existent data.
- Test input validation.
- Test API behavior with different permissions.
1.9. Direct test procedure
Scheduling API testing every day while the testing process is in operation is highly recommended. Because the API testing implementation is fast, stable and small enough, it is easy to add more tests to the current test process with minimal risk. This is only possible with automated API testing tools that come with features such as:
- Schedule a test with the commands included in the tool
- Integrates with test management tools and error tracking tools
- Seamless integration with various CI tools
- Create visual log reports
When the test is complete, you can get the results of the tests every day. If test failures occur, you can test the outputs and confirm the problems for a suitable solution.
1.10. Do not underestimate automation API testing
The test API flow is quite simple with three main steps:
- Send request with necessary input data
- Get feedback with output data
- Test that the response returns as expected in the requirement
The most sensitive part of API testing is not to send requests or receive responses. It’s about managing data testing and validation. The common thing is that testing the first few APIs like logging in, querying some resources, etc. is quite simple. The test task is becoming more and more difficult for the next API. Therefore, the test API task is easy to be underestimated. At some point, you’ll find yourself in the middle of choosing a good method for test data and a test method. That is because the returned data is similar in structure, but not the same in a test project. It will be difficult to decide whether you should test JSON / XML data by key or not, or use code.
It is highly recommended to consider automation API testing in a project, so that the structure can be expanded, reused and maintained.