Error Handling Test for Web Applications Without Coding

Writing code that works when everything functions as expected can be termed as Happy Path Coding. It is a desirable state but this does not happen as often as expected. An experienced developer thinks of all possible use cases and corner cases and makes sure his code informs the users of an application if an unexpected error happens. This level of coding is brilliant and the best way to operate in Software Engineering.

But sometimes developers tend to forget to consider users when rushing to meet deadlines or if they are inexperienced and ignore their coding for errors.

Let’s say you are building a Web Application that will fetch a list of products that users can browse and pick. For this, the web application might be calling a REST Endpoint to fetch the list of products(Eg:- GET https://yourbackendapi/products).

Typically, developers will expect that the REST Endpoint will always respond with SUCCESS response (200 ok) and ignore error scenarios like 401(Unauthorised Exception), 500 (Internal Server Error), 502 (Bad Gateway), etc. 

When a web application does not give an informed response to a customer and pushes the app to an "unknown state or view", you finally end up with an unhappy customer

Displaying a message such as - “Looks like we are running into an issue. Please contact Tech Support @ [email protected] if the problem persists” delivers a better user experience and is far preferable to displaying an exception message that says something like “Unexpected end of JSON input at 0”.

How can the QA team identify these types of errors and find badly handled error scenarios?

They may have access to the code, but they may lack the experience to read through it and understand all of the poorly handled pieces of code. In addition, having to replicate 4XX, 5XX errors means they will have to depend on the API team which is may not be a feasible and scalable approach.

To help with this, the QA team can use any of the help tools listed below to fish out all the bad API error-handled scenarios without touching any code or contacting the API team.

The first tool that I would like to recommend is Requestly, a browser extension that enables to intercept all the API calls passing through the browser. Once intercepted, it can then redirect the API call or modify the request/response headers.

The second tool that I would like to introduce is Mockoon, a tool that can be installed on Windows or Mac or Linux and build mock API in seconds.

Using Requestly and Mockoon , to test the underlying API call (in our example above (GET https://yourbackendapi/products) can be intercepted and redirected to a mock API which is built using Mockoon.

The mock API can then be configured to respond with 4xx or 5xx errors to see how your web application handles these API errors.

Hence, this test will enable the QA team to identify whether the web application is gracefully handling the errors, providing users with informative messages rather than throwing technical jargon responses.

Architecture Design for Error Handling Testing

Here is a step-by-step flow to the configuration :

1. Identify the use case and API that’s being called to display the data in the user interface. In our example, it is “https://yourbackendapi/products”.

2. Create a mock API using Mockoon to respond with 500.

3. Create a Redirect rule called getProducts in Requestly to redirect the actual API to mock API

4. Save the Rule and make sure it is ON.

5. Now, go to your web application and execute the use case i.e. in our example get Products.

Check how the User Interface is responding to different errors. If API responds with a 500 message, the user interface should respond with a message like “Something went wrong. Please contact [email protected] if the problem persists rather than an ugly tech-riddled message.

Troubleshooting tips:

- Make sure HTTPS is enabled on the mockAPI if your web application is on HTTPS.

- Make sure CORS is enabled if you observe any CORS errors.

- As the mock API is running on localhost, the browser might hinder the API in the pre-flight stage saying “ERR_CERT_AUTHORITY_INVALID”. To get over this, try accessing https://localhost:3000/respondwith500 in the browser and allow “Proceed to localhost(unsafe)”

I hope this post has been useful in identifying bad error handling scenarios in your web applications.

Let me know! Reach out on my socials with your comments.