Let’s not get lost into all that “testing your software is important” thing. I really hope you already know that.
You will also learn how to upload your code coverage to coveralls.io so you can keep track of it and have a nice badge on your repository’s README.md file.
LET’S START THIS, FAST
Whoa, calm down champ, one thing at a time.
First of all let’s create a module, so we will have something to test.
If you already have something to test and don’t want to waste your time creating a new dummy module please skip the next two chapters and go straight to “Can we finally go on to gulp?“
Open your terminal and run
npm init. Fill in all the requested information and it will generate a
package.json file for you.
Now we’re going to run these commands in order to install every module we need:
At this time you may be wondering: “why did I install Gulp two times?”. You did it because we need to have gulp available at the command line so we can run commands such as
gulp test. Then you installed it using the
--save-dev flag, which installs Gulp locally and saves it into your module’s
devDependencies, this means everyone who runs
npm install at your module’s directory will have Gulp downloaded so they can run the tasks you’ve created.
Hey, wait, what about the module?
Well observed, sir, we do not have the module’s code yet. For this tutorial we will create a simple module that does sums and subtractions.
This is our module’s code:
coolModule.js file inside a folder called
Okay, but we still have no tests…
Don’t worry, we will have some very soon.
As we will use gulp-mocha to run tests, we’re going to write a test file using mocha’s features, obviously. These are our tests:
tests.js file inside a folder called
Can we finally go on to gulp?
YES! We finally can!
Now we’ve got our module and our tests ready to run we will create some gulp tasks to test our module and then get coverage information.
Before writing actual tasks we will need to
require some modules.
Okay, now let’s create a task called “pre-test”. This task will be responsible for piping our module’s files into istanbul, by doing this we will be able to know which parts of our code were tested and which weren’t.
All we’ve gotta do now is create a task (that depends on the
pre-test task) to actually run our tests. This is it:
Feel free to run your tests running
gulp test on your terminal.
The results will be located at a folder called
That’s nice! How can I upload this to coveralls.io?
First of all go to https://coveralls.io/sign-up and sign up. If this is your first time at coveralls and you logged in using GitHub you may need to authorize access to your GitHub account.
Select your desired repository and turn on the activation button. When clicking on
DETAILS you will be able to see what is your token. Save this token into a file called
.coveralls.yml on your repository’s root folder.
Aaaaaaaaaaand we’re finally done! Run
gulp coveralls and you will get your coverage data uploaded to coveralls.
Oh, and before I forget, here comes a nice tip: if you want to upload your coverage results only when running the coveralls task from a CI service, like travis-ci, your
coveralls task should be something like this:
What do these
line criteria mean?
- Function Coverage indicates how many functions were executed
- Branch Coverage indicates how many if/else branches were executed
- Statement Coverage indicates how many statements in the program were executed
- Line Coverage indicates how many lines were executed
Is there anything else I should be aware of?
Yes, there actually is!
coverage/lcov-report there’s a file called
index.html, if you are having trouble getting 100% coverage on any possible criteria such as branches, functions or lines you should open this with your favorite browser and then you will be able to navigate through your project’s files and see which parts aren’t being tested.
In this post you should’ve learned:
- How to test your modules using Gulp, Mocha and Chai
- How to get coverage reports using Istanbul
- How to send your coverage reports to Coveralls
- The meaning of each coverage criteria
- How to spot what parts of your code aren’t being tested