As a developer, it’s not often that you run across software that instantly changes the way you work, but last night I found a new and as of yet relatively unknown package that for me did just that.
Enter Wallaby.js, the little Atom package (plugins available for IntelliJ & Visual Studio at a fairly steep price) that promises to provide live testing and code coverage in your editor as you type. The video on their site looks pretty impressive, but given the *cough*hideous*cough* look of their site, the fact that it’s in beta, has a whopping 200 downloads, and knowing first-hand how complicated implementing something like can be — let’s just say I was a bit skeptical at first. After I did install it the lack of decent documentation on how to get it to work and the random errors after I do exactly what it told me to don’t exactly instill confidence! But skip past all that and here we are:
The Setup
To get started, you need to install node.js and Atom, a relatively new open-source editor developed by github. Early versions of Atom were plagued with performance problems, though since the 1.0 release those are mostly gone. Where the editor really shines is in its extensibility. Atom has more than 2,500 available packages.
Once you have atom installed, open the preferences and install Wallaby:
To get you started, I’ve created a github repository with some sample code (that we will fix) and a Wallaby config file.
Clone the git repository at https://github.com/zyklus/article-wallaby.git, go to the newly created project directory and type npm install to install our single project dependency.
Now open this folder in Atom and let’s get started. The first thing you need to do in your own projects is create a Wallaby config file. The project’s author suggests using wallaby.js or wallaby.json. Personally, I’m using .wallabyrc which follows the naming convention of other packages like linters and has the advantage of not showing up in a directory listing by default.
Configuring Wallaby
If you look at the .wallabyrc file in your project you’ll see that it’s pretty simple:
files is a list of all your source files (lib/**/*.js tells the editor to look for all JavaScript files in the lib directory and any sub-directories), and tests is a list of all your test files. If you are using ES6+ in your project, you can enable support via the environment options at the bottom of this file.
Now tell Wallaby to use this file by right-clicking anywhere in the file and selecting “Select as Wallaby.js Config”. You are supposed to be able to do this from the tree menu as well (so that you don’t need to open the file), but that wasn’t working for me.
For the tests in this project, I’m using CoffeeScript. I’m generally not a fan of CoffeeScript for various reasons (though plenty of people are), but I think it makes for beautiful unit tests. If you’re not familiar with it it’s a very similar syntax to JavaScript so it hopefully won’t look too foreign to you.
To the code!
Now open test/numbers.coffee and start wallaby by opening its command palette (cmd+shift+space) and typing start (alternatively you can open the normal command palette (cmd+shift+p) and type wallaby start.
You’ll notice that line 19 has an error on it via both the red box to the left of the line number and the red text to the right:
Apparently my random little fun code snippet to parse numbers from strings doesn’t handle negative numbers. Oops! Let’s fix that, shall we?
Open up lib/numeric-string-parsers.js and head to line #23. Apparently someone commented it out, so remove the comments and now our tests should pass.
You’ll notice that the lines turn green almost the moment we un-comment those two lines of code and our tests pass. This is beautiful!
We have a few more things to fix before we’re done, however. If you scroll down a bit you’ll notice that some of the lines in our .js file have grey boxes next to them:
These boxes signify that this part of our code isn’t tested! There is plenty of discussion on the web as to whether you need 100% code coverage or not, but I think these lines in particular should certainly be covered by tests.
If you return to our test file, numbers.coffee, you’ll notice that a few lines of tests are commented out. Uncommenting them will enable the tests that check whether a few large numbers pass. Return to numeric-string-parser.js to see that the boxes are now green and all of our code is tested!
That’s it! You now have unit tests and code coverage that update, in your editor, as you code! Yay!
