Cover image for Learning JavaScript Testing Quickly with Mocha, Chai, and Sinon (and a Lot of Gaps)

Learning JavaScript Testing Quickly with Mocha, Chai, and Sinon (and a Lot of Gaps)

isalevine profile image Isa Levine Updated on ・5 min read

Cover image credit: Hunter x Hunter manga by Yoshihiro Togashi, meme-ified by yours truly. <3

Update 8/9/19: This article has been dubbed Part 1 of my new series, Junior JavaScript Jobhunting: Quick Tips for Technicals and Takehomes! Hope you enjoy and find some useful tips, and please feel free to contribute more in the comments!

anime gif of suited man sipping tea with a satisfied look on his face

Recently, I had the opportunity to complete a takehome coding challenge that required me to include JavaScript tests with my solution. I will freely admit that I am still learning the ins-and-outs of testing, and that a big part of the battle is knowing what to test. These notes are not intended as a primer on testing generally—instead, I wanted to share the commands and syntax needed to get up-and-running quickly, and get some unit tests written.

So what are we testing here?

The challenge involved building a class, FlavorRanker, that takes in a text file to parse and returns a ranking of most popular flavors. The parsed rankings are stored in a property, this.flavorObj, that is initialized empty, and is filled after running the class function parseTextFile(). Here’s a snapshot of a simplified version:

// FlavorRanker.js

class FlavorRanker {
    constructor() {
        this.flavorObj = {};

    parseTextFile() {    
    // fill in this.flavorObj with pairs like “grape”: { “points”: 5 }
exports.FlavorRanker = FlavorRanker;

With this class, there’s a few things we can test right away:

After an instance of FlavorRanker is created, does its this.flavorObj property exist?
At certain points, is this.flavorObj empty—or has parseTextFile() successfully added name-value pairs to it?
Has parseTextFile() been called—and has it been called exactly once?

Not the most robust tests, but they’ll introduce us to some essential JavaScript testing syntax from frameworks Mocha, Chai, and Sinon!

Wait, why are we covering three things at once?

Short answer: because they work so well together! Briefly, here’s what each of them will do for us:

  • Mocha - A JavaScript test runner and framework that provides a describe()/it() syntax for testing assertions. This will be the thing specified in your package.json file under “scripts”: { “test”: “mocha” }.

  • Chai - A library that adds extra readability to JavaScript test assertions. Supplants the Node.js default assert() syntax with expect().to.be, and lots of chain-able options.

  • Sinon - A library that provides spies that “watch” functions and can detect when they’re called, what arguments are passed to them, what is returned, etc. (Sinon provides a lot more than that, but we’ll stick with just spies for this post.)


To include these packages in your project, use the following commands:

$ npm install -g mocha - this will install Mocha globally (not just in your current project), and give you access to $ mocha commands in your terminal. (This guide won’t cover that.)

$ npm install chai - this will install Chai locally.

$ npm install sinon - this will install Sinon locally.

You will also want to create a /test directory, and a test.js file inside that directory:

|-- test.js

Finally, in your package.json file, check your “scripts” section to make sure “test” is set to “mocha”:

// package.json

"scripts": {
  "test": "mocha"

Let’s write some tests!


Let’s load some specific tools into our tests. We’ll be using Chai’s expect, Sinon’s spy, and the FlavorRanker class from above:

// test.js 

const expect = require('chai').expect;
const spy = require('sinon').spy;
const FlavorRanker = require('../flavorRanker.js').FlavorRanker;

Use describe() to organize tests and create contexts

Mocha allows us to write tests by nesting describe() functions within each other. This StackOverflow discussion goes into some of the when/why/how of organizing tests, but here’s the gist:

describe(“String with test description”, function() { … } )

NOTE: This article covers why you DON’T want to use arrow functions instead of function() {} in Mocha.

You can nest these as deeply as you want—just be aware that each one establishes a new context, and that variable scoping applies here as expected:

describe('Generic test name', function() {
    // variable flavorRanker does NOT exist in this context.

    describe('FlavorRanker class', function() {
        const flavorRanker = new FlavorRanker;

        describe('flavorRanker instance', function() {
            // variable flavorRanker DOES exist in this context.

Use it() to declare a single test

Within a describe() context, each it() function describes a single test. The syntax is:

it(“String with test description”, function() { … } )

Here are two tests ensuring that a newly-created instance of FlavorRanker has a this.flavorObj property, and that it’s an empty object:

describe('flavorRanker instance', function() {

            it('should have a flavorObj property that is an object', function() {
                // testable assertion

            it('flavorObj should be empty', function() {
                // testable assertion

Chai: expect()

Chai shines because it makes writing readable tests so simple. Here’s the syntax for expect():

expect(foo).to._____._____._____ …

In the blanks, you can add a host of chain-able functions that create the testable assertion. Here’s how we can write expect() functions for the two tests above:

describe('flavorRanker instance', function() {

            it('should have a flavorObj property that is an object', function() {

            it('flavorObj should be empty', function() {

The tests will check exactly what they say: is flavorRanker.flavorObj an object, and is it empty? Here’s the terminal output from running $ npm test:

  Generic test name
    FlavorRanker class
      flavorRanker instance
        ✓ should have a flavorObj property that is an object
        ✓ flavorObj should be empty

Sinon: spy()

Finally, we can use Sinon’s spy() function to assign a variable to “watch” for certain behaviors, like the function being called or returning a value. To create a spy:

const spyName = spy(object, “functionName”)

For our tests, we’ll create a spy for flavorRanker’s parseTextFile() method:

        describe('flavorRanker instance', function() {
            const parseTextFile = spy(flavorRanker, "parseTextFile");

And now, we can write tests using Chai’s syntax to check if it’s been called exactly once:

describe('flavorRanker instance', function() {
    const parseTextFile = spy(flavorRanker, parseTextFile");

    // spy detects that function has been called

    // checks that function was called once in this test’s context
    it('flavorRanker.parseTextFile() should be called once', function() {


Now, when we run $ npm test again, our terminal shows:

  Generic test name
    FlavorRanker class
      flavorRanker instance
        ✓ should have a flavorObj property that is an object
        ✓ flavorObj should be empty
        ✓ flavorRanker.parseTextFile() should be called once


Conclusion: This is only the beginning!

As I stated in the intro, this writeup is NOWHERE NEAR comprehensive—but for folks like me who are a little daunted by starting to learn JavaScript testing, having just a couple easy-to-use tools can help you get started! Please feel free to leave comments below sharing any other intro-level tips for someone who needs to learn some testing syntax quick!

(More Comprehensive) Guides and Resources

Excellent introductory guide to Mocha, with a lot more depth

Great tutorial to help you write your first tests

Excellent cheat-sheet of Mocha, Chai, and Sinon syntax

Mocha docs

Chai docs

Sinon docs

Posted on by:

isalevine profile

Isa Levine


Isa (ee-suh). She/her pronouns. Full stack developer working with Rails and Vue. Drinks too much bubbly water.


markdown guide

Awesome article! I am also a huge fan of Jest with Kent C Dodds testing-library one is specifically called react-testing-library. Overall I love the testing philosophy and mindset that it was built from and enforces.


Thank you Jacob! I just spent this past week with someone who works with Jest, so it's definitely calling to me more and more...I imagine this article will have a little testing-sibling soon! :P


Hi, I removed the #beginners tag. The tag should be for devs on the 0-2/10 scale. You can check the updated guidelines for the tag here :


I'm actually pretty flattered that I've apparently gone beyond the 0-2/10 range! :D

I appreciate the updated guidelines too, thanks for sending that along!


Thank you for the content, Isa!


Great article, exactly what I needed to learn about testing and apply it in my internship! Thanks a bunch, Isa :)