The Five Most Common Bugs you Should be Writing Tests for
Tags: testing, productivity, devops
Published: 2019-10-31 17:09:01

Users have higher expectations than ever before. At the same time, the customer experience is [increasingly the top priority](https://www.forbes.com/sites/forbescommunicationscouncil/2018/12/11/why-customer-experience-has-never-been-more-vital/#3dfe634e7b7b) because of its far-reaching implications with respect to customer activation and retention. 

The easiest way to kill a good customer experience is with a bad bug. That's where tests come in. 

Tests are instrumental to delivering a good customer experience – they spot bugs before the customer ever has a chance to. 

Some technologies like static typing and linting can help get you part of the way there, but ultimately, you should be writing tests to ensure your business logic and the corresponding customer experience work as you'd expect them to.  

At [walrus.ai](http://walrus.ai), we help teams automate their most annoying integration tests. We've outlined some of the most frequent bugs that our customers have experienced that you can write simple tests to prevent. 

# **What are the most common bugs you should be writing tests for?**

## **Unresponsive interactive elements**

Unresponsive elements are deadly. Often they manifest themselves in onboarding experiences (continue buttons, input forms, etc.), and can prevent the customer from taking a valuable action, such as signing up, or in the instance below, getting a car loan! 

![A gif of an unresponsive slider on a car website](https://thepracticaldev.s3.amazonaws.com/i/tuag3i86l7etsjsqg1i6.gif)

## **Form validation**

Forms are where you collect the most important business data from your customers. Whether it's their credit card information, or information that will be used to engage the customer (such as email and phone number, the quality of this data is certainly important to the business, and can have a meaningful impact on the customer experience (for example, when you are scheduling a demo and enter an incorrect phone number!). 

![A gif of someone entering 415 into a phone number field](https://thepracticaldev.s3.amazonaws.com/i/2ezby8aa989ccnto036x.gif)

## **Asynchronous data**

User actions that have asynchronous dependencies are particularly prone to bugs, and can have significant implications for the business. For example, if you don't evaluate whether someone has previously claimed a promotion code fast enough, your system provides a window for coupon fraud. 

![Gif of a promo code being applied twice](https://thepracticaldev.s3.amazonaws.com/i/pam0ipagoe7j0zx8ydht.gif)

## **Empty data**

Empty data errors occur when users expect certain results (like search results, or data represented in a report), but the frontend doesn't render any real results, despite the data existing. These bugs are particularly frustrating for the user, because it isn't even clear that an error is occurring. 

![An image of an empty report](https://thepracticaldev.s3.amazonaws.com/i/1c2s8c3kgn29r1fb5f68.png)

## **Multiple popups or modals**

Modals are a great way to engage users — whether it's introducing them to a new feature in your product, or merchandising a discount. But not both at the same time.

Not only are overlapping modals problematic [with respect to ADA compliance](https://www.w3.org/TR/wai-aria-practices/#dialog_modal), they also dilute the call-to-action for the end-user, and generally make your product look untrustworthy.  

![A gif of many popups being stacked on top of each other](https://thepracticaldev.s3.amazonaws.com/i/wupr7be4mjs9sslxnl0w.gif)

# Writing tests sucks. How can I make it painless?

It's hard to write tests because computers don't think like humans do. 

A human thinks about what the user is trying to accomplish in a particular experience (say, checkout), and wants to make sure that the user can successfully accomplish that task. But computers require much more specific instructions — make sure this button is green and contains specific text, for example. Writing tests requires humans to think like computers.

**But there are new ways of writing tests!** 

With [walrus.ai](http://walrus.ai), you can write complex integration tests with one line of code, in plain english. 

[Try it for free!](http://walrus.ai)

![An integration test being run on walrus](https://thepracticaldev.s3.amazonaws.com/i/rfsmmrmle65lctbp1siu.gif)