Originally published by Isa Levine at dev.to
Recently, I had the opportunity to complete a take-home 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.
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.jsclass 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!
Short answer: because they work so well together! Briefly, here’s what each of them will do for us:
describe()
/it()
syntax for testing assertions. This will be the thing specified in your package.json file under “scripts”: { “test”: “mocha” }
.assert()
syntax with expect().to.be
, and lots of chain-able options.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
|-- 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 export
, Sinon’s spy
, and the FlavorRanker
class from above:
// test.jsconst expect = require(‘chai’).expect;
const spy = require(‘sinon’).spy;
const FlavorRanker = require(‘…/flavorRanker.js’).FlavorRanker;
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. }); });
});
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 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() { expect(flavorRanker.flavorObj).to.be.an('object'); }); it('flavorObj should be empty', function() { expect(flavorRanker.flavorObj).to.be.empty; });
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
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”);it('should have a flavorObj property that is an object', function() { expect(flavorRanker.flavorObj).to.be.an('object'); }); it('flavorObj should be empty', function() { expect(flavorRanker.flavorObj).to.be.empty; }); });
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 flavorRanker.parseTextFile(); // checks that function was called once in this test’s context it('flavorRanker.parseTextFile() should be called once', function() { expect(parseTextFile.calledOnce).to.be.true; }); });
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
Perfect!
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!
Originally published by Isa Levine at dev.to
===========================================
Thanks for reading :heart: If you liked this post, share it with all of your programming buddies! Follow me on Facebook | Twitter
☞ Learn Javascript Unit Testing With Mocha, Chai and Sinon
☞ Svelte.js - The Complete Guide
☞ The Complete JavaScript Course 2019: Build Real Projects!
☞ Become a JavaScript developer - Learn (React, Node,Angular)
☞ JavaScript: Understanding the Weird Parts
☞ JavaScript: Coding Challenges Bootcamp - 2019
☞ The Complete Node.js Developer Course (3rd Edition)
☞ Angular & NodeJS - The MEAN Stack Guide
☞ NodeJS - The Complete Guide (incl. MVC, REST APIs, GraphQL)
☞ Node.js Absolute Beginners Guide - Learn Node From Scratch
#javascript #web-development