Testing JavaScript Applications

Lucas Fernandes da Costa

• Publisher: Manning Publications
• Year: 2021
• ISBN:
  9781617297915
• Topic: Computer Science
• Subtopic: Programming in JavaScript
• Index: Computer Science

Automated testing will help you write high-quality software in less time, with more confidence, fewer bugs, and without constant manual oversight. Testing JavaScript Applications is a guide to building a comprehensive and reliable JS application testing suite, covering both how to write tests and how JS testing tools work under the hood. You'll learn from Lucas de Costa, a core contributor to popular JS testing libraries, as he shares a quality mindset for making testing decisions that deliver a real contribution to your business. You'll benefit from informative explanations and diagrams, easily-transferable code samples, and useful tips on using the latest and most consolidated libraries and frameworks of the JavaScript ecosystem.

Part 1. Testing JavaScript applications

Whether you’re designing a website for your uncle’s bakery or a stock-trading platform, the most critical characteristic of your software is whether it works. Your uncle’s customers will certainly order more cheesecakes if you have an intuitive and beautifully designed website. In the same way, brokers on Wall Street will make more money if your platform is fast and responsive. Still, users will blatantly ignore all the effort invested in performance and design if your software is unreliable.

If a program doesn’t work, it doesn’t matter how beautiful or fast it is. Ultimately, kids want more sugar and brokers want to trade more stocks. None of them wants more software.

The first part of Testing JavaScript Applications explains how automated tests help you give people what they want: software that works. Furthermore, it teaches you how to deliver that software in less time with more confidence.

In chapter 1, I’ll introduce automated tests and describe how they can help you and your team.

Chapter 2 presents multiple types of automated tests. It explains when to write each type of test, the pros and cons of each type, and the fundamental patterns you’ll apply throughout the whole book.

1 An introduction to automated testing

This chapter covers

• What an automated test is
• The goal of writing automated tests
• How automated tests can help you write better code, in less time, with more confidence

When everything runs on software, from your uncle’s bakery to the country’s economy, the demand for new capabilities grows exponentially, and the more critical it becomes to ship software that works and ship it frequently—hopefully, multiple times a day. That’s what automated tests are here for. Long gone is the time when programmers could afford themselves the luxury of manually testing their software every once in a while. At this point, writing tests is not only good practice, it’s an industry standard. If you search job postings at this very moment, almost all of them require some degree of knowledge about automated software testing.

It doesn’t matter how many customers you have or the volume of data you deal with. Writing effective tests is a valuable practice for companies of every size from venture-capital-backed Silicon Valley giants to your own recently bootstrapped startup. Tests are advisable for projects of all sizes because they facilitate communication among developers and help you avoid defects. Because of these reasons, the importance of having tests grows proportionally to the number of developers involved in a project and to the cost of failure associated with it.

This book is targeted at professionals who can already write software but can’t yet write tests or don’t know why it’s critical to do so. While writing these pages, I had in mind people who are fresh out of bootcamps or recently got their first development job and want to grow into seniority. I expect readers to know the basics of JavaScript and understand concepts like promises and callbacks. You don’t need to be a JavaScript specialist. If you can write programs that work, that’s enough. In case the shoes fit, and you’re concerned about producing the most valuable kind of software—software that works—this book is for you.

This book is not targeted at quality assurance professionals or nontechnical managers. It covers topics from a developer’s point of view, focusing on how they can use tests’ feedback to produce higher-quality code at a faster pace. I will not talk about how to perform manual or exploratory testing, nor about how to write bug reports or manage testing workflows. These tasks can’t be automated yet. If you want to learn more about them, it’s advisable to look a book targeted at QA roles instead.

Throughout the book, the primary tool you will use is Jest. You will learn by writing practical automated tests for a few small applications. For these applications, you’ll use plain JavaScript and popular libraries like Express and React. It helps to be familiar with Express, and especially with React, but even if you are not, brief research should suffice. I’ll build all of the examples from scratch and assume as little knowledge as possible, so I recommend to research as you go instead of doing so up-front.

In chapter 1, we’ll cover the concepts that will permeate all further practice. I find that the single most prominent cause of bad tests can be traced back to a misunderstanding of what tests are and what they can and should achieve, so that’s what I’m going to start with.

Once we have covered what tests are and the goal of writing them, we will talk about the multiple cases where writing tests can help us produce better software in less time and facilitate collaboration among various developers. Having these conceptual foundations will be crucial when we start writing our first tests in chapter 2.

1.1 What is an automated test?

Uncle Louis didn’t stand a chance in New York, but in London, he’s well-known for his vanilla cheesecakes. Because of his outstanding popularity, it didn’t take long for him to notice that running a bakery on pen and paper doesn’t scale. To keep up with the booming orders, he decided to hire the best programmer he knows to build his online store: you.

His requirements are simple: customers must be able to order items from the bakery, enter the delivery address, and check out online. Once you implement these features, you decide to make sure the store works appropriately. You create the databases, seed them, spin up the server, and access the website on your machine to try ordering a few cakes. During this process, suppose you find a bug. You notice, for example, that you can have only one unit of an item in your cart at a time.

For Louis, it would be disastrous if the website went live with such a defect. Everyone knows that it’s impossible to eat a single macaroon at a time, and therefore, no macaroons—one of Louis’s specialties—would sell. To avoid that happening again, you decide that adding multiple units of an item is a use case that always needs to be tested.

You could decide to manually inspect every release, like old assembly lines used to do. But that’s an unscalable approach. It takes too long, and, as in any manual process, it’s also easy to make mistakes. To solve this problem, you must replace yourself, the customer, with code.

Let’s think about how a user tells your program to add something to the cart. This exercise is useful to identify which parts of the action flow need to be replaced by automated tests.

Users interact with your application through a website, which sends an HTTP request to the backend. This request informs the addToCart function which item and how many units they want to add to their cart. The customer’s cart is identified by looking at the sender’s session. Once the items were added to the cart, the website updates according to the server’s response. This process is shown in figure 1.1.

Figure 1.1 An order’s action flow

NOTE The f(x) notation is simply the icon I’ve chosen to represent functions throughout this book’s diagrams. It doesn’t necessarily indicate what the function’s parameters are.

Let’s replace the customer with a piece of software that can call the addToCartFunction. Now, you don’t depend on someone to manually add items to a cart and look at the response. Instead, you have a piece of code that does the verification for you. That’s an automated test.

Automated test Automated tests are programs that automate the task of testing your software. They interface with your application to perform actions and compare the actual result with the expected output you have previously defined.

Your testing code creates a cart and tells addToCart to add items to it. Once it gets a response, it checks whether the requested items are there, as shown in figure 1.2.

Figure 1.2 The action flow for testing addToCart

Within your test, you can simulate the exact scenario in which users would be able to add only a single macaroon to their cart:

1. Create an instance of a cart.
2. Call addToCart and tell it to add a macaroon to that cart.
3. Check whether the cart contains two macaroons.

By making your test reproduce the steps that would cause the bug to happen, you can prove that this specific bug doesn’t happen anymore.

The next test we will write is to guarantee that it’s possible to add multiple macaroons to...