top of page

Unified or Separate API & UI Automated Test Tools?



Hammer and screws

For a long time, I have firmly believed in using the right tool for the right job. It only seems logical, right?

This has also led me, correctly or incorrectly, to assume that a tool has one primary purpose and that anything else it does won't be done as well as a dedicated tool.


As a result, over the years, I have developed a set of preferred API & UI automated test tools that I tend to rely on and recommend. However, I have had to re-assess this view recently when working with a client.


Data

This particular client wanted a new automation framework. They had redesigned their entire application, and their old suite was no longer fit for purpose and had to be discarded. The application in question was very data-heavy, with the UI acting as a presentation layer, lots of graphQL API calls, and lots of processing behind the scenes. In this situation, my go-to would be Cypress for the UI tests and SuperTest for the API calls. Traditionally, I have steered away from using Cypress's API capability as it needs to spin up the browser and execute from there, adding some extra overhead in time and, in this day and age, CI/CD pipeline costs.


As we analysed which tool to use, I wondered if it would be easier for the client's QA team to use one tool for both. It would be less to learn and all in one place, so there would be a definite benefit there.


So, a POC was produced in Cypress (it was between that and Playwright, and I have used Cypress more) that tested both the UI and API aspects of the system, and I was pleasantly surprised! The similarities between the API and UI tests were a real benefit, making the framework more straightforward to learn. It even allowed for more intricate tests, so rather than using an Intercept, we could select an API call to provide the required data and ensure that it matched what the UI was displaying. It also helped solve a problem with the automation test user's setup. The client ID and client secret weren't captured when the user was created, making login via the API impossible. The fallback was capturing the token when logging in via the UI.


This also streamlined the reporting, as we could use the Mochawesome Cypress plug-ins to produce one unified report for all the tests run without extra complications.


In summary, don't be afraid to try something for extra practicality. You never know; it may prove beneficial. Just don't get stuck on one tool. Not everything is a nail, so you don't always need a hammer!



 
 
 

Comentaris


bottom of page