The Art of Unit Testing with examples in JavaScript Third Edition Version 7

195 Pages·2022·5.093 MB·English

by  Roy Osherove

MEAP Edition
Manning Early Access Program
The Art of Unit Testing
with examples in JavaScript
Third Edition
Version 7
Copyright 2022 Manning Publications
For more information on this and other Manning titles go to
manning.com
©Manning Publications Co. To comment go to liveBook
welcome
Thanks for purchasing the MEAP for The Art of Unit Testing 3rd Edition, with Examples in
Javascript.
This book has been written to take most anyone from never doing unit testing in Javascript
to being able to write real world unit tests on real projects with real code.
We will begin at the very basics of what makes good unit tests, and move to mocks, stubs,
async work and refactoring. We’re using Jest as our test framework but that shouldn’t stop
you from using any other unit test framework for your purposes.
The book assumes that you’re already familiar with Javasctipt ES2015 and that’s it. It
should fit well whether you’re a backend or frontend developer because the examples will try
to be as agnostic as possible to the various frameworks out there such as Express, React or
Angular, and instead focus on the patterns underlying the code structures, so that you should
be able to approach most any task with the knowledge that you’ve seen this pattern before,
be it with a slightly different disguise.
—Roy Osherove
©Manning Publications Co. To comment go to liveBook
brief contents
PART 1: GETTING STARTED
1 The basics of unit testing
2 A first unit test
PART 2: CORE TECHNIQUES
3 Breaking dependencies with stubs
4 Interaction testing using mock objects
5 Isolation (mocking) frameworks
6 Unit Testing Async Code
PART 3: THE TEST CODE
7 Trustworthy Tests
8 Maintainability
PART 4: DESIGN AND PROCESS
9 Readability
10 Working with legacy code
11 Design and testability
©Manning Publications Co. To comment go to liveBook
1
Part 1
Getting started
This part of the book covers the basics of unit testing.
In chapter 1, I’ll define what a unit is and what “good” unit testing means, and I’ll compare
unit testing with integration testing. Then we’ll look at test-driven development and its role in
relation to unit testing.
You’ll take a stab at writing your first unit test using Jest (A very common JavaScript test
framework) in chapter 2. You’ll get to know Jest’s basic API, how to assert things, and how to
execute tests continuously.
©Manning Publications Co. To comment go to liveBook
2
1
The basics of unit testing
This chapter covers
• Defining entry points & exit points
• Defining a unit of work & unit tests
• Contrasting unit testing with integration testing
• Exploring a simple unit testing example
• Understanding test-driven development
SOME ASSUMPTIONS BEFORE WE BEGIN:
You already know basic usage of NODE.JS and node package manager (NPM). You know how to use GIT source
control. You’ve seen github.com before and you know how to clone a repository from there. You’ve written
code in JavaScript , either backend or frontend code, and you can understand basic ES6 JavaScript code
examples
CAN YOU USE THIS BOOK FOR NON JAVASCRIPT USE?
Yes. The previous editions of this book were in C#. I’ve foun that about 80% of the patterns there have
transferred over quite easily. So you should be able to read this book eve if you come from Java, .NET, Python,
Ruby or other languages. The patterns are just patterns. The language being used is there just so we can
demonstrate those patterns. But they are not language specific.
©Manning Publications Co. To comment go to liveBook
3
1.1 The first step
There’s always a first step: the first time you wrote a program, the first time you failed a
project, and the first time you succeeded in what you were trying to accomplish. You never
forget your first time, and I hope you won’t forget your first tests.
• You may have come across them in some form; Some of your favorite open source
projects come with bundled up “test” folders, you have them in your own project at
work.
• You might have already written a few tests yourself, and you may even remember
them as being bad, awkward, slow, or unmaintainable. Even worse, you might have felt
they were useless and a waste of time. (Many people sadly do.)
• On a more upbeat note, you may have had a great first experience with unit tests, and
you’re reading this to see what more you might be missing.
This chapter will first analyze the “classic” definition of a unit test and compare it to the
concept of integration testing. This distinction is confusing to many, but is very important to
learn because, as we’ll learn later in the book, separating unit tests from other types of tests
can be crucial to having high confidence in your tests when they fail or pass.
We’ll also discuss the pros and cons of unit testing versus integration testing and develop a
better definition of what might be a “good” unit test. We’ll finish with a look at test-driven
development, because it’s often associated with unit testing, but is a separate skill that I
highly recommend giving a chance (it’s not the main topic of this book though). Throughout
the chapter, I’ll also touch on concepts that are explained more thoroughly elsewhere in the
book.
First, let’s define what a unit test should be.
1.2 Defining unit testing, step by step
Unit testing isn’t a new concept in software development. It’s been floating around since the
early days of the Smalltalk programming language in the 1970s, and it proves itself time and
time again as one of the best ways a developer can improve code quality while gaining a
deeper understanding of the functional requirements of a module, class or function.
Kent Beck introduced the concept of unit testing in Smalltalk, and it has carried on into
many other programming languages, making unit testing an extremely useful practice in
software programming.
To see what we don’t want to use as our definition of unit testing, let’s first look to
Wikipedia as a starting point. I’ll use this one because there are many important pats missing
for me but it is largely “accepted” by many for lack of other good definitions.. It’ll be slowly
evolving throughout this chapter, with the final definition appearing in section 1.8.
DEFINITION 1.0 (WIKIPEDIA) Unit tests are typically automated tests written and run by software
developers to ensure that a section of an application (known as the "unit") meets its design and behaves as
©Manning Publications Co. To comment go to liveBook
4
intended. In procedural programming, a unit could be an entire module, but it is more commonly an individual
function or procedure. In object-oriented programming, a unit is often an entire interface, such as a class, but
could be an individual method.
The thing you’ll write tests for is called the “SUT”.
DEFINITION SUT stands for subject, system or suite under test, and some people like to use CUT
(component, module or class under test or code under test). When you test something, you refer to the thing
you’re testing as the SUT.
Let’s talk about the word “unit” in unit testing. To me, a unit stands for “unit of work” or a
“use case” inside the system. A unit of work has a beginning and an end. I call these entry
points and exit points. A simple example of a unit of work, as we’ll soon see, is a function that
calculates something and returns a value. But that function could also use other functions ,
other modules and other components in the calculation process, which means the unit of work
(from entry point to exit point), now spans more than just a function.
Definition : Unit of Work
A unit of work is the sum of actions that take place between the invocation of an entry point up until a noticeable end
result through one or more exit points. The entry point is the thing we trigger. Given a publicly visible function, for
example:
The function’s body is all or part of the unit of work.
The function’s declaration and signature are the entry point into the body.
The resulting outputs or behaviors of the function are its exit points.

1.3 Entry Points & Exit Points
A unit of work always has an entry point and one or more exit points.
Figure 1.1 shows a simple diagram of how I think about Units of Work:
©Manning Publications Co. To comment go to liveBook
5

Figure 1.1: A Unit of work has entry points and exit points.
A unit of work can be a single function, multiple functions, multiple functions or even multiple
modules or components. But it always has an entry point which we can trigger from the
outside (via tests or other production code), and it always ends up doing something useful. If
it doesn’t do anything useful, we might as well remove it from our codebase.
What’s useful? Something publicly noticeable happens in the code: A return value, state
change or calling an external party. Those noticeable behaviors are what I call exit points.
Listing 1.1 will show a simple version of a unit of work.
©Manning Publications Co. To comment go to liveBook
6

Figure 1.2: Types of Exit Points
Why “exit point”?
I got asked by an early reviewer of this book why I choise to use “exit point” and not something like “behavior”. My
thinking is that behaviors can also be purely internal. We’re looking for externally visible behaviors from the caller. That
distinction might be difficult to differentiate during “live action” coding. Also, “exit point” has the nice connotation to it
that suggests we are leaving the context of a unit of work and going back to the test context. Behaviors might be a bit
more fluid than that. That said, I’m not sure. Perhaps this will change in the 4th edition of this book…

Listing 1.1 shows a quick code example of a simple unit of work.
Listing 1.1: A simple function that we’d like to test.
/ch1/number-parser.js
const sum = (numbers) => {
const [a, b] = numbers.split(',');
const result = Number.parseInt(a, 10) +
Number.parseInt(b, 10);
return result;
};

module.exports.sum = sum;
©Manning Publications Co. To comment go to liveBook