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 mktg@inapp.com 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 4 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 Data.gov 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.

  3. Nikhilesh Prasad

    Hi,
    a front-end application using REST APIs.

    1. Where would you start? What would be your first steps?
    2. Which process would you establish around testing new functionality? How would you
    want the features to be tested?
    3. Which tools would you suggest using to help your team with a daily work?
    4. If you would do a test automation which techniques or best practices would you use the
    application?

    Can you elaborate and explain each part ?

    1. Rubina Mary Thomas

      Hi Nikhilesh,

      It is not an API testing tool, but API mocking tool to help the UI development independent of the backend development.
      We can use this tool to review how the UI/front-end application behave when different responses(HTTP status codes such as 200, 404, 400, 500 ) etc occurs,
      such scenarios are difficult to create a project.

      1. Where would you start? What would be your first steps?
      The REST API definition is the contract between the front end and back end of the application. So first step should be defining the APIs.
      The server-side development not yet started, but if we want to demo a click-through or proceed with the UI development then we can introduce the iBounce.

      2. Which process would you establish around testing new functionality? How would you
      want the features to be tested?
      As the first level, we need to define the API structure, its responses, and different HTTP status codes. These data will be populated in the ibounce and then we can start the testing UI against different test cases.

      3. Which tools would you suggest using to help your team with a daily work?
      Swagger-swagger is an open source software framework backed by a large ecosystem of tools that helps developers design, build, document, and consume RESTful Web services
      Ibounce- API Mocking tool to test Front-end client application
      Postman- HTTP client for testing web services.

      4. If you would do a test automation which techniques or best practices would you use the
      application?
      We can use ibounce to test the behavior of front-end client application against different error/exception conditions which are difficult to recreate in the real-time project. Example for such cases is how the UI behave if the API returns HTTP error code 404 or 500

Leave a Reply

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