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 software development projects API testing is a challenge. In large projects, generally, there are two teams working. One of 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 they would have to spend time in 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 are returned? The client must behave predictably and gracefully but testing this was extremely difficult.
In order to solve this problem, we needed a tool which would insert itself between the Web-Client (Browser, Phones etc.) and the Server (Private, Cloud or Third Party) and Mocks 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 which 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 back-end RESTful services – web browser (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 (may be external) and the client. This makes the operation easy.
6. Have the ability to run from 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.
Contact us to know more about iBounce or to schedule a demo (email@example.com).