We have heard of many people really struggle with API testing. Many of our fellow colleagues and some of the customers would talk about their problems while doing API testing.
We tried to investigate the causes of these problems. We found that in large custom software development projects, API testing is a challenge. In large projects, generally, there are two teams working. One on the back end and one on the front end. The speeds of the two teams never match and each team is waiting for the other to test. The folks developing the front end would either wait for the back-end folks to be ready or would have to spend time creating mock objects for front-end testing.
Then there were software development projects which had interactions with external servers. Generally, there is no control over an external server. Again the only way to test the API would be to create mock objects. This would consume a lot of programming time.
Generic problems related to API testing
Other than these specific cases, there were some generic problems related to API testing. These problems were all-pervasive, across all projects. For example: “testing for error response.” The test case that was often left untested was how the client behaves when the server sends an error response. How does the client behave when an HTTP status of 500 is returned or when a 4xx or 3xx is returned? The client must behave predictably and gracefully but testing this was extremely difficult.
In order to solve this problem, we needed a tool that would insert itself between the Web-Client (Browser, Phones, etc.) and the Server (Private, Cloud, or Third Party) and mock the Server. Thus the client would feel that the server is available in all respects and the Client testing can proceed even if the server is not available. We didn’t find a tool that would provide this solution. Hence we went about developing this tool which we have now come to call “iBounce.”
Some of the key features of iBounce are:
1. Support MockServices:
It introduces itself between the Web-Client and Application-Server and Mocks the Server. The Web-Client can be anything that consumes backend RESTful services – web browsers (HTML/JS), Phones, or other devices. The Application-Server is a server exposing a REST API.
2. Allow Sharing of Test Cases across platforms:
iBounce does not per-se do test cases but it defines each interaction between the server and the client. As we call it “The Contract” between the Client and the Server. The contracts between the client and server remain the same regardless of the Phone / Browser used and in this way defines Test-Cases can be shared between devices/web-browser. This supports test automation in many ways and is very useful when we do not have access to a third-party such as Google APIs, AWS Management APIs, Financial Services, or Data.gov APIs.
3. Support File Access: We could load the Contract Information from files.
4. Easy for Non-Technical Use: Designed primarily for non-technical use.
5. Easy to create and validate test cases:
We have implemented API capture. This is useful to initially create the Contract / Test Cases between the Server (maybe external) and the client. This makes the operation easy.
6. Have the ability to run from a CI environment:
In the CI environments, while executing test jobs for the Client (only), the server and APIs must have already been tested. In many instances, we do not have the server ready or the server is not available for testing as it is a third-party server. In these cases, we introduce iBounce to mock the server and run the test cases in the CI environment.
iBounce is being developed in a DevOps mode and is under continuous development and we expect to add many more features soon.
