We often hear terms like in-sprint automation or shift left, but do we know how to achieve this? In this blog, we will learn about mock API response and their relationship with UI testing, which will help to find and prevent defects early in the software delivery process.

In today’s fast-paced world, everyone wants to develop their software faster while making it more robust. Due to this, the most impactful phase of SDLC (Software Development Life Cycle) is the testing phase, and in general, this can be a relatively short time scale.

Because of the short period, complete reliance on UI testing alone is unsuitable for creating a robust software program.

Provar testing pyramid demonstrates the testing process for product development and how mock API response testing can help

The above image of the test automation pyramid demonstrates that API test cases are faster and more reliable than UI test cases. Provar recommends that our customers follow a hybrid approach, deploying both UI testing and mock API response test cases.

However, if you are beginning your software production journey, you may ask yourself exactly how the two differ.

What is UI Testing?

UI stands for ‘User Interface,’ and whether you’re using a CLI (Command Line Interface) GUI (Graphic User Interface), or even a mixture of both, UI testing involves assessing the usability of your application from how easy the interface is to use to how the application responds to command lines or interacting with buttons, sliders, and visual components.

You need to take a manual and automated approach to UI testing. This is because appearance and impression are crucial aspects of this stage and are unattainable via automated testing. However, automated testing will help you achieve shorter release cycles and quality baselines. 

You’ve probably already concluded that UI testing is a vital component of the product life cycle, and you would be correct. Lack of UI testing may result in the product’s release with a hidden bug in the user interface or an unnecessarily complex design, which could ultimately lead to users opting for a more user-friendly alternative.

How Should You Leverage Mock API Responses?

Firstly, API (Application Programming Interfaces) contains the application logic, such as how users can interact with the software and what functions are included. Mock APIs can imitate predefined API responses, such as, for example, responses from a database query or an answer that limits the number of records that can be entered on specific subscriptions.

API testing works between each application layer, whether data, service, or presentation, and mock API testing allows automated service responses to data and service requests.

Mocking API responses can help you in building your API automation test cases.

Let’s understand how you can achieve this with Provar.

Collaboration is the key.

As the heading suggests, collaboration is one of the most impactful strategies to minimize time and maximize coverage.

Collaborating with your dev team and discussing the approach they are following while developing the product can help highlight areas in which Mock API responses could be helpful throughout the development cycle, i.e., a ‘shift left’ approach.

What is Shift Left Automation Testing?

Shift left automation testing, also referred to as ‘shift left software testing, is the agile practice of moving the testing phase as early in the Software Development Life Cycle (SDLC) as possible, rather than sticking to traditional methods of leaving testing to the near end of the SDLC.

Provar's SDLC diagram illustrates the classic approach to software development

The above diagram illustrates the phases taken in the SDLC process. In a traditional approach, testing wouldn’t begin until the software is up and running; a left-shift approach allows testing to be an integral part of the development. This helps prevent defects early in the software development process and adopts a more economical approach as the software can be reactively developed to overcome any problems discovered in the initial phases. This is where in-sprint automation can be a valuable asset. 

In-sprint automation differs from N-1 Sprint automation by prioritizing a Test Driven Development (TDD) approach in which developers begin with unit tests before developing the functional code. 

Below is an example of a TDD approach paired with Mock API response testing.

Step 1. Obtain the JSON response that can be used for TDD from your development team:

{

    “id”: 1,

    “name”: “The Russian”,

    “author”: “James Patterson and James O. Born”,

    “isbn”: “1780899475”,

    “type”: “fiction”,

    “price”: 12.98,

    “available”: true

}

Step 2. In the Provar test palette, drag the ‘set values’ to your test case: 

Provar Testing mock API palette

Step2. Using the JSON response code as a reference, set the values of your test case to match:

Provar Testing test parameters

Step 3. Drag one or more set values to set the response status:

Provar Testing Rest Response setup

Step4. Let’s run the test case and see how the mocked response will look in variables.

Provar Testing API mock response variables

Awesome, we have successfully mocked the API response. Moreover, we can use this response in further test case steps.

Step5. Disable the set values step and give the name to the result of the API step ‘RestResponse.’

Provar Testing, name your mock API response

Step 6. Run and see the response in the variable section.

Provar Testing response variable section

This should match the mocked response.

As you can see, mock API responses are a fantastic solution for building your automation test cases. They aid in defining the final product early by using a test-driven approach suitable for agile teams with short SDLCs.

Check out our documentation resource for more information on how Provar Testing can be used. You can also join our new Provar Community to participate in discussions and collaborate with other Provar users.