Front End API Testing – A Neglected Area

* How do you test if the incoming API Calls to back-ends are correct?
* How do you test if the front-end behaves properly on APIs returning errors?
* How do you test front end before the back-end is ready?


The New Emerging Architecture

API Testing Tool

With the emergence of Smartphones and HTML5, the front-end of application software has clearly separated from the back-end. The MVC5 of Microsoft, Java, PhP, Android and iOS allows clear separation of the front-end and back-end. in a typical environment, the Back-end applications usually expose themselves as REST API to which the front-end calls using XML or lately JSON.

The Gap

While there are many tools to test the Back-End, the database access, the API testing, back-end security, there are few tools to check the API Calls! The problem is aggravated when the APIs are third-party APIs which you do not have access.

What do we do?

The only way would be to capture the API calls from our front end and Bounce back the expected (contracted) reply from the server and check against that.

Such a tool could also return HTTP status 200, 300, 404, 500 and other errors, enabling us to test the front-end under different API return values! Test out in HTTP and the new HTTP/2 protocols.

iBounce – API Testing Tool 

API Testing Tool


At InApp we have developed an effective API Testing Tool to do precisely that. We call it iBounce! This API Testing Tool  has increased our productivity tremendously by helping us develop the front-end of applications, which consume public APIs and helped us in developing Front-End and Back-End by two teams asynchronously. Thus the front-end and back-end teams are not waiting perpetually for each other; Solving a lot of project management deadlocks.

Email us at to try out iBounce.

Amarnath Raja is the CEO and co-founder of InApp and is responsible for the overall strategy at InApp. He is an alumnus of the IIT-D and is a seasoned technology expert with several years of experience working for IBM Japan, JP Morgan Chase and ‘milma’. He is an active member of IEEE and has held the positions of Kerala Section Chair and IEEE Humanitarian Committee Chair. In 2015, he received the prestigious LKW Transnational Award from IEEE. He was also the Trivandrum Chapter Chair of Computer Society of India.

This Post Has 2 Comments

  1. anonymous

    Can your tool do the following?
    1 – support Mockservices
    2 – allow the sharing of test cases
    3 – Support Rest API
    4 – support database access (Postgressql)
    5 – support file access(Excel, cvs)
    6 – Easy for non technical individuals to use
    7 – Easy to create and validate test cases
    8 – Have the ability to run from our CI (Bamboo) environment

  2. Abhishek Raj

    1. Support MockServices
    Yes. iBounce does exactly that.
    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 – WebBrowser (HTML/JS), Phones or other devices. The Application-Server is a server exposing a REST API.

    2. Allow Sharing of Test Cases.
    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 APIs.

    3. Supports REST API. – Yes. This is primarily designed for REST API.

    4. Support Database Access – In this environment we do not see the need for accessing a DB for implementing test cases. Currently we only use a DB (sqlite) to keep the ‘Contract’ information and the logs. We could use DBs like Postgres if the size becomes too large.

    5. Support File Access: We could load the Contract Information from files.

    6. Easy for Non-Technical Use – Yes designed primarily for non-technical use.

    7. 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.

    8. Have the ability to run from our CI (Bamboo) 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. Though as a company, we do not use Bamboo, we feel such an arrangement in Bamboo environment will increase your productivity.

    Having said that iBounce is being developed in a devops mode and is under continuous development and any features that you may require could be added within a short time.

Leave a Reply

Your email address will not be published. Required fields are marked *