When should we do API testing? Let's test the API now!
Hello everyone, I am Mai Cuong from RakAPIt Team.
Are you developing API? How does testing work?
Surely many people have heard about API Testing but do not understand it very well. That's why today's article I will write about this topic.
About API
I am very passionate about Web development.
The first project I joined was developing on a PHP framework called Laravel. Laravel is a great framework, very popular for developing in PHP language. However, I encountered some problems such as: it was quite difficult to manage the server, divide the work within the team, and testing was also very difficult. Then I learned about another framework called React. At that time, the concept of Serverless was a very hot topic, I started developing by combining React and Serverless. I had heard a lot about the API before, but it wasn't until then that I started to learn more about it.
API is an acronym for Application Programming Interface. As we know, the mechanism for interaction between the user and the application is called User Interface (UI). Similarly, you also need a mechanism to interact between applications, which is API.
At first, the API was adopted by chance, but during the product development process, I realized it has many advantages.
First of all, the development process is simplified. By dividing it into Frontend and Backend, we were able to speed up development. In addition, since there is no need to develop for each mobile device or browser, we have been able to reduce the amount of development.
API are highly independent and can be considered as an "object". We can easily embed those components not only in new projects but also in existing projects, and can also be shared between different projects. For example, you will often see the Google Map API or Facebook API built into a website or applications.
In addition, API deployment is also very easy. Because the API is independent, when updating, we do not need to deploy the entire project, we only need to deploy the necessary content.
About API Testing
When I first started working with API, even though the development process changed, the testing process was still conducted the same as before. After writing Unit Testing for Frontend and Backend, integration testing will be performed. Then there is System Testing and finally Acceptance Testing. But I started to realize there was a problem.
The problem lies in testing the combination, including combining inside the Backend and combining the Backend with external systems. We cannot solve this problem with Unit Testing, and can only proceed on UI. However, testing on UI will take a lot of effort and time. Even more critical is that testing starts very late in the product development process. If an error is discovered here, the effort required to correct it will be huge. To better understand this issue, please refer to Capers Jones' chart below.
Source: The Shift-Left Approach to Software Testing
Could we have done combined testing earlier?
After doing some research, I learned that testing at the API level can solve the above problems. We can start hybrid testing at an earlier stage, because we can start testing the moment the API is completed without having to wait for the UI to complete.
Besides, there are many other benefits. First, even if the Test case is difficult to execute with the UI, if you call the API directly it can still be done. For example, let's say you have a form that has input validation. If you enter incorrect data, an error message will be displayed and the "Submit" button will be disabled. At that time, we need to confirm that the Backend will be processed as expected even if unusual data is sent. If we test from the UI, we will have to temporarily disable the Input Validation function, then enter abnormal data and send it. However, by testing the API, it is not necessary to do those things.
Also, API testing is simpler and takes less time than UI testing, making it more suitable for automation.
API Testing will be conducted after performing Unit Testing. Like the Test Pyramid below, we see that, after carefully performing Unit Testing, the next step is to conduct API testing with as wide a scope as possible.
Source: Test Automation
What to do practically?
Because the API is considered a "object", we will perform testing of each "object" (like Unit Testing) and test the combination of "objects" together.
Unit Testing of API here also means Component Testing. Here, we will confirm whether for each Request, the Response is returned as expected or not. We will check that for normal, abnormal or any cases that may occur, the server processes and returns the correct Response. Because there are many different data samples, there are often quite a few Test cases here.
Next is testing the combination of "objects" together, that is, testing the API script. We will imagine scenarios that happen when users use the application and test them. For example, at an online store, the following scenario can be assumed:
- API Login
- List of products API
- Product details API
- Add Cart API
- Payment API
Challenges in API Testing
The first thing you face when trying to test an API is "How should I test it?". In general, it is possible to immediately learn how to send Requests and receive Responses, but the most difficult thing is "How to test?", or what is called test design.
Next is the workload. First of all, creating Test cases is not an easy task. We will have to think about test data and combine those data to create Test cases. After having test cases, you must build a test environment and run the tests. Since it is a combination of data, there are many test cases and test execution often takes time. Because you have to combine data together, there are many test cases and it will usually take a lot of time to perform the test.
Also, test case management is difficult, including test case creation and editing. Whenever something is updated, it is a repetitive process of modifying the test cases and re-executing them.
Although there are many benefits, there are many people who give up API Testing thinking of such a large workload.
Can those problems be resolved?
After conducting API Testing through trial and error, I realized how hard API Testing is, and I started working with my team to develop a tool to make API Testing easier.
RakAPIt is an acronym for "Raku API Testing", with the meaning of aiming for "easy and fun API Testing". So, how will RakAPIt solve the above problems?
First, not knowing how to perform testing, in other words difficulty accessing API Testing. RakAPIt supports design and has the ability to automatically generate test cases simply by entering data patterns. In addition, if the API definition is written in Swagger files, the test data is also automatically generated, and even the assertion of the Response is automatically generated. The execution of the test is also fully functional, and the test is executed at the push of a button.
The next problem is the heavy workload. With RakAPIt, both test design and test execution are automated. In addition, test management is greatly reduced by being able to centrally manage everything from test case creation, to test case additions and modifications, to results confirmation, all on the web. Furthermore, because it is a Web Service, environment setup is not necessary, and can be started immediately with just User registration.
Summary
In this article, we discussed what API Testing is and the concept of API Testing.
In the next article, I would like to talk about how to perform API Testing using RakAPIt.
Please look forward to the next article!
