We often hear terms like in-sprint automation or shift left, but do we actually know how to achieve this? In this blog, we will learn about mock API responses 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 whilst 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 time span, complete reliance on UI testing alone is not a suitable approach to creating a robust software program.
The above image of the test automation pyramid demonstrates that API test cases are faster and more reliable than UI test cases, which is why we at Provar recommend our customers follow a hybrid approach, deploying both UI testing as well as mock API test cases.
However, if you are just beginning your software production journey, you may be asking 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) or 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.
For UI testing you need to take both a manual and automated approach. This is because the look and feel are important factors of this phase and can’t be achieved through automated testing but automated testing will help you achieve shorter release cycles and quality baselines.
You’ve probably already come to the conclusion that UI testing is a vital component of the product life cycle and you would be correct, without UI testing the product could be released with an underlying bug in the user interface or be overly complicated and dropped for something that users find easier to use.
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 a response that limits the number of records that can be entered on specific subscriptions.
API testing works between each layer of the application, whether that be 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 one can adopt 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 practices of leaving testing to the near end of the SDLC.
The above diagram illustrates the phases taken in the SDLC process. You can see that in a traditional approach, testing wouldn’t begin until the software is up and running, a shift left 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 will 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:
“name”: “The Russian”,
“author”: “James Patterson and James O. Born”,
Step 2. In the Provar test palette, drag the ‘set values’ to your test case:
Step2. Using the JSON response code as a reference, set the values of your test case to match:.
Step 3. Drag one or more set values, to set the response status:
Step4. Let’s run the test case and see how the mocked response will look in variables.
Awesome, we have successfully mocked the API response. We can use this response in further steps of the test case.
Step5. Disable the set values step and give the name to the result of the API step ‘RestResponse’.
Step 6. Run and see the response in the variable section.
This should match the mocked response.
As you can see, mock API responses are a fantastic solution in building your automation test cases and can be used early in the development process to help define the final product with a test-driven approach, making it a perfect medium for agile teams with short SDLC’s.
For more information on ways in which Provar Testing can be used, check out our documentation resource, you can also join our new Provar Community to participate in discussions and collaborate with other Provar users.