Testing, Testing: Read all about It

Introduction

Being a coding bootcamp graduate, testing in code was a big part of my bootcamp experience. A lot of our independent learning and homework required completing labs, which required passing all of the tests written for that said lab. So, I used used to running the test suite, and either gloriously seeing all the tests pass in green, or having those dreaded red tests, meaning they’ve failed and I need to re-check my work. That said, my experience was only in running tests. Writing them was a whole other story.

In the majority of articles written about post-bootcamp learning or feedback giving about job searching, writing tests, or unit testing, comes up frequently. Amongst other reasons, unit testing helps find bugs, and that’s always important.

I wanted to take a stab at it and see what it’s all about. Let’s take a look at the journey so far.

Setting Up

The majority of my post-bootcamp concentration has been in JavaScript, so I’ve been unit testing in JS. JS has two major frameworks when it comes to testing: Mocha and Jest. The testing for our labs had been in Mocha, so I wanted to start there. As always, reference the official docs for deeper dives.

To get started, install Mocha either globally to the machine or as a dependency to the project. I chose to the project, so in the project file, install using:

$ npm install --save-dev mocha

And then also run:

$ npm install mocha

In order to run tests, Mocha will look for a folder in you project called test, so make a test folder as well

$ mkdir test

Assertion Libraries

Unit testing also requires an assertion library. The assertion library is what does the actual verification of the results. In Mocha, the default library is assert. While this library is totally fine, there are some others that allow for a few more features like Chai. I chose to use Chai, so don’t forget to

$ npm install --save-dev chai

package.json

The package.json file should now have these dev dependencies

dev dependencies

Now that all of the dependencies installed, let’s set up our test script. To do so, add the following test script in package.json. This allows tests to be run on the command line by using

$ npm test

test script

Getting Started

Sweet. Everything is installed and package.json looks good. Time to start writing some tests. The main file for my project is index.js. So, in the tests folder, I have a file called index-tests.js.

For getting started, I had a function in mind that I wanted to test. The function is a simple sum function — taking in an array as an argument, adding all the elements, and returning the sum.

One important thing to note: in order for the test to have access to the function, the function has to have module.exports. That can either be equal to an anonymous function. Or, if multiple functions from the same file are desired, it can be set up as an object with key/value pairs. Here, I have a key sum, pointing to my function.

Test Time

Importing

First thing to do, import the applicable interface(s) from Chai and any local files.

Exporting the sum function from earlier makes it accessible through requiring it. This allows it to be used later on in our tests. That function is then saved as a variable. We can name the variable anything we’d like, it is a variable after all. But, for the sake of consistency, I’ve called it sum.

Building the Test

Tests generally have a formula.
1.) Describe what’s to be tested
2.) Written explanation of what should happen
3.) Results to verify
And, luckily, most tests read as if it’s prose. So, it’s pretty intuitive to decipher.

The describe statement gets two arguments. The first argument is a string declaring what I’m testing. Again, anything can be put here, but for continuity’s sake, it’s best to put the function name or whatever is being tested. The second argument is a function. That function opens up into the second bullet point — written explanation. This, too, gets two arguments. The first argument is the explanation of what’s trying to be achieved. Once again, since it’s a string, anything can be put here. But, a concise description of what’s trying to be accomplished is best. The second argument is a function. That function opens to the results needed to be verified. Notice the pattern here? Declaration — logic — function , repeat as needed.

In the suite, there’s two tests. The first is checking to make sure that the elements are added correctly. It’s saying, describe sum. It should return the sum of all the elements added to together. Using the expect interface from Chai, it’s verifying that it should expect 1+2+3+4+5 to equal 15. THIS is our test case.

Our second test is saying, expect the sum function to return a number. Since, it’s an addition function, this makes sense. A number is a desired result. Anything other type, ie. array, object, string, etc., would throw an error.

Testing

Now that everything is in place, let’s run npm test.

Beautiful! Two passing tests. Notice how what’s being tested and the description of the tests are the string descriptions from the test suite? This is why is best to be as accurate and descriptive as possible.

Conclusion

While there is a bit of boilerplate and code needed to create tests, I found it easy to get the hang of, and rather easy to write. All it takes is some practice. After my experience, I’d say that Mocha plus Chai is a solid combination for getting started with unit testing. I look forward to creating tests for my algorithm practice as well as implementing it in future projects. Give it a shot for yourself! As always, reference the official docs, and happy coding!