This article was peer reviewed by Panayiotis «pvgr» Velisarakos, and Tom Greco. Thanks to all of SitePoint's peer reviewers for making SitePoint content the best it can be!
Have you ever made some changes to your code, and later found it caused something else to break?
I'm sure most of us have. This is almost inevitable, especially when you have a larger amount of code. One thing depends on another, and then changing it breaks something else as a result.
[author_more]
But what if that didn't happen? What if you had a way of knowing when something breaks as a result of some change? That would be pretty great. You could modify your code without having to worry about breaking anything, you'd have fewer bugs and you'd spend less time debugging.
That's where unit tests shine. They will automatically detect any problems in the code for you. Make a change, run your tests and if anything breaks, you'll immediately know what happened, where the problem is and what the correct behavior should be. This completely eliminates any guesswork!
In this article, I'll show you how to get started unit testing your JavaScript code. The examples and techniques shown in this article can be applied to both browser-based code and Node.js code.
The code for this tutorial is available from our GitHub repo.
What is Unit Testing
When you test your codebase, you take a piece of code — typically a function — and verify it behaves correctly in a specific situation. Unit testing is a structured and automated way of doing this. As a result, the more tests you write, the bigger the benefit you receive. You will also have a greater level of confidence in your codebase as you continue to develop it.
The core idea with unit testing is to test a function's behavior when giving it a certain set of inputs. You call a function with certain parameters, and check you got the correct result.
// Given 1 and 10 as inputs...
var result = Math.max(1, 10);
// ...we should receive 10 as the output
if(result !== 10) {
throw new Error('Failed');
}
In practice, tests can sometimes be more complex. For example, if your function makes an Ajax request, the test needs some more set up, but the same principle of "given certain inputs, we expect a specific outcome" still applies.
Setting Up the Tools
For this article, we'll be using Mocha. It's easy to get started with, can be used for both browser-based testing and Node.js testing, and it plays nicely with other testing tools.
The easiest way to install Mocha is through npm (for which we also need to install Node.js). If you're unsure about how to install either npm or Node on your system, consult our tutorial: A Beginner's Guide to npm — the Node Package Manager
With Node installed, open up a terminal or command line in your project's directory.
- If you want to test code in the browser, run
npm install mocha chai --save-dev
- If you want to test Node.js code, in addition to the above, run
npm install -g mocha
This installs the packages mocha
and chai
. Mocha is the library that allows us to run tests, and Chai contains some helpful functions that we'll use to verify our test results.
Testing on Node.js vs Testing in the Browser
The examples that follow are designed to work if running the tests in a browser. If you want to unit test your Node.js application, follow these steps.
- For Node, you don't need the test runner file.
- To include Chai, add
var chai = require('chai');
at the top of the test file. - Run the tests using the
mocha
command, instead of opening a browser.
Setting Up a Directory Structure
You should put your tests in a separate directory from your main code files. This makes it easier to structure them, for example if you want to add other types of tests in the future (such as integration tests or functional tests).
The most popular practice with JavaScript code is to have a directory called test/
in your project's root directory. Then, each test file is placed under test/someModuleTest.js
. Optionally, you can also use directories inside test/
, but I recommend keeping things simple — you can always change it later if necessary.
Setting Up a Test Runner
In order to run our tests in a browser, we need to set up a simple HTML page to be our test runner page. The page loads Mocha, the testing libraries and our actual test files. To run the tests, we'll simply open the runner in a browser.
If you're using Node.js, you can skip this step. Node.js unit tests can be run using the command mocha
, assuming you've followed the recommended directory structure.
Below is the code we'll use for the test runner. I'll save this file as testrunner.html
.
<!DOCTYPE html>
<html>
<head>
<title>Mocha Tests</title>
<link rel="stylesheet" href="node_modules/mocha/mocha.css">
</head>
<body>
<div id="mocha"></div>
<script src="node_modules/mocha/mocha.js"></script>
<script src="node_modules/chai/chai.js"></script>
<script>mocha.setup('bdd')</script>
<!-- load code you want to test here -->
<!-- load your test files here -->
<script>
mocha.run();
</script>
</body>
</html>
The important bits in the test runner are:
- We load Mocha's CSS styles to give our test results nice formatting.
- We create a div with the ID
mocha
. This is where the test results are inserted. - We load Mocha and Chai. They are located in subfolders of the
node_modules
folder since we installed them via npm. - By calling
mocha.setup
, we make Mocha's testing helpers available. - Then, we load the code we want to test and the test files. We don't have anything here just yet.
- Last, we call
mocha.run
to run the tests. Make sure you call this after loading the source and test files.
The Basic Test Building Blocks
Now that we can run tests, let's start writing some.
We'll begin by creating a new file test/arrayTest.js
. An individual test file such as this one is known as a test case. I'm calling it arrayTest.js
because for this example, we'll be testing some basic array functionality.
Every test case file follows the same basic pattern. First, you have a describe
block:
describe('Array', function() {
// Further code for tests goes here
});
describe
is used to group individual tests. The first parameter should indicate what we're testing — in this case, since we're going to test array functions, I've passed in the string 'Array'
.
Secondly, inside the describe
, we'll have it
blocks:
describe('Array', function() {
it('should start empty', function() {
// Test implementation goes here
});
// We can have more its here
});
it
is used to create the actual tests. The first parameter to it
should provide a human-readable description of the test. For example, we can read the above as "it should start empty", which is a good description of how arrays should behave. The code to implement the test is then written inside the function passed to it
.
All Mocha tests are built from these same building blocks, and they follow this same basic pattern.
- First, we use
describe
to say what we're testing - for example, "describe how array should work". - Then, we use a number of
it
functions to create the individual tests - eachit
should explain one specific behavior, such as "it should start empty" for our array case above.
Continue reading %Unit Test Your JavaScript Using Mocha and Chai%
by Jani Hartikainen via SitePoint
No comments:
Post a Comment