5 Essential Tips for Testing JavaScript UIs
Tags: testing, tips, javascript
Published: 2022-03-13 10:42:41

---
title: 5 Essential Tips for Testing JavaScript UIs
published: true
date: 2021-06-30 00:00:00 UTC
tags: testing, tips, javascript
canonical_url: https://pragmaticpineapple.com/5-essential-tips-for-testing-javascript-uis/
---

When it comes to writing tests for (JavaScript) UIs, you either like it or not. But, if you’re inside a company that demands a certain test coverage threshold, or you want to have logic covered, you will have to do it eventually. Whatever your case is, I believe the following five tips will help you write better tests.

![Lavander field](https://miro.medium.com/max/1050/0*6wehmIg6j6R9KvrY)<figcaption>
  Photo by <a src="https://unsplash.com/@anniespratt?utm_source=medium&amp;utm_medium=referral">Annie Spratt</a> on <a src="https://unsplash.com?utm_source=medium&amp;utm_medium=referral">Unsplash</a>
  </figcaption>

I struggled a lot with writing tests when starting. The concept was pretty straightforward — you write code that validates other code you wrote. But, something was off back then, and I was not too fond of it at first. Fast forward a couple of years later, and I am now okayish with writing tests. I got my head around it. These are the tips I find most useful on day to day basis of writing UI tests.

## [<svg aria-hidden="true" focusable="false" height="16" version="1.1" viewbox="0 0 16 16" width="16"><path fill-rule="evenodd" d="M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z"></path></svg>](#1-test-behavior-not-implementation)1. Test Behavior, Not Implementation\*\*

For some, it might come naturally to follow the principle of testing UI behavior rather than implementation. But trust me, sometimes, in the depths of the test code, you might lose this idea and try to hack your way out of the test.

If you are familiar with Test Driven Development ([**TDD**](https://en.wikipedia.org/wiki/Test-driven_development)), there is also Behavior Driven Development ([**BDD**](https://en.wikipedia.org/wiki/Behavior-driven_development)). The idea is to create a script using a DSL (Domain-Specific Language) that almost everyone on the project can understand. For a long time, the primary tool to make it with was [Cucumber](https://cucumber.io/) (the library, not the vegetable). It would allow you to form a test script like so:

Feature: Put items in the cart Scenario: Breaker joins a game Given the user has visited the awesome shopping page When the user adds an item to the cart Then the user should see the item in the cart

The idea is simple, and the implementation uses the Gherkin syntax with “Given”, “When”, and “Then” format. Scripts like these are there to have stakeholders read them and understand the features and scenarios, but I rarely see them reading them in practice.

Anyways, if you are not a fan of such tools, you can skip using it (duh), but keep in mind that you should test behavior.

## [<svg aria-hidden="true" focusable="false" height="16" version="1.1" viewbox="0 0 16 16" width="16"><path fill-rule="evenodd" d="M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z"></path></svg>](#2-test-one-thing-at-a-time)2. Test One Thing At a Time

One great tip I’d give to myself a couple of years ago was to focus on testing one thing in one test. I used to test lots of different things in one test. One good thing that Cypress framework does is that they advise only to test the login functionality **once** and log in programmatically in all other tests.

So let’s say you are testing the adding an item to the shopping cart. Ideally, it would be best if you focused on that piece of UI functionality in the test. All of the other things like:

- logging in,
- seeding the items to be added to the card,
- publishing the store where the user will purchase the items

should all be part of the setup. You shouldn’t do all of these things directly in the test, but instead, just focus on the actions user takes to add an item to the cart.

## [<svg aria-hidden="true" focusable="false" height="16" version="1.1" viewbox="0 0 16 16" width="16"><path fill-rule="evenodd" d="M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z"></path></svg>](#3-structure-tests-properly)3. Structure Tests Properly

Another thing that will set you up for success in testing is to follow the AAA patterns. AAA stands for the following:

- 1st A — **Arrange** : Put and perform everything needed to set up the test for the functionality that is about to get tested. Seed the data, log in the user, stub calls, etc.
- 2nd A — **Act** : Execute the actions like adding an item to the cart.
- 3rd A — **Assert** : Ensure that the received value satisfies the expectation. Make sure the test validates the expected behavior.

Go ahead, and try it out in your next test.

## [<svg aria-hidden="true" focusable="false" height="16" version="1.1" viewbox="0 0 16 16" width="16"><path fill-rule="evenodd" d="M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z"></path></svg>](#4-use-helpers-to-generate-test-data)4. Use Helpers to Generate Test Data

Often, you face the same problem — the creation of particular data objects in tests. Whether that’s a product, user, random item, you have to create the object somehow in the test setup. One software design pattern that can help you out here is the [Factory pattern](https://en.wikipedia.org/wiki/Factory_method_pattern).

One library that can help us with generating objects is the [Fishery](https://github.com/thoughtbot/fishery) library. If you’re using TypeScript, these two can fit in perfectly. Let’s say we want to generate a user in our test. One way to do it is like this:

```typescript
// factories/user.ts

import { Factory } from "fishery"
import { User } from "../my-types"
import postFactory from "./post"

export const userFactory = Factory.define<User>(({ sequence }) => ({
  id: sequence,
  name: "Rosa",
  address: { city: "Austin", state: "TX", country: "USA" },
  posts: postFactory.buildList(2),
}))

```

Then, we can create the user without too much fuss like so:

```javascript
const user = userFactory.build({ name: "Sandra" })
```

You should now have more precise tests because you can generate objects without specifying all the attributes, only the ones relevant to the current test you are writing. Also, the user factory definition is in one place, and you can easily edit it from there, no need to go through all your tests when some attributes change.

## [<svg aria-hidden="true" focusable="false" height="16" version="1.1" viewbox="0 0 16 16" width="16"><path fill-rule="evenodd" d="M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z"></path></svg>](#5-avoid-sleeping-in-tests)5. Avoid Sleeping (In Tests)

We’ve all been there, setting some timeout to handle an async test case or to force the next tick. With the new tools, you don’t have to do this. If you’re testing some async code, you can use Jest to test it:

```javascript
test("the data is peanut butter", async () => {
  const data = await fetchData()
  expect(data).toBe("peanut butter")
})
```

With the simple _async / await_ syntax, no more of the _setTimeout_ is needed. Or, better yet, if you’re using [Cypress](https://www.cypress.io/), they have an integrated waiting mechanism that will give a certain amount of time for each command to perform. Also, in the _testing-library_, you can do _waitFor_ like described in [its docs](https://testing-library.com/docs/dom-testing-library/api-async/#waitfor).

Anyways, whatever you do, think twice before you call `setTimeout` or any other time-related methods because it will make your tests less readable and possibly flaky.

## [<svg aria-hidden="true" focusable="false" height="16" version="1.1" viewbox="0 0 16 16" width="16"><path fill-rule="evenodd" d="M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z"></path></svg>](#sum-up)Sum Up

Thanks for reading these five tips. I hope that you gained some insight after them. Also, I hope these help you write better UI tests for your JavaScript apps.

If you’re interested in more blog posts like these, consider subscribing to the [newsletter](https://pragmaticpineapple.com/newsletter). Also, if you find this blog post useful, you can share it with your friends and colleagues on Twitter below:

{% twitter 1410249787543363584 %}

Catch you in the next one, cheers.