As a developer, I get that we don’t like paying for tools. This is especially true when there are so many free options out there. For me this was easy… if there’s something that saves me time and makes my experience better, I’ll consider it. What sells me on Wallaby.js is that it removes the dread factor in having “ugh, I have to go run my tests” in the back of my head… Wallaby.js makes it stupid simple and does it for me. Thus, it promotes good development practices. It also stays out of my way and works all the time in the background. I had no problem getting a $100 license for VSCode.
See Wallaby.js In Action
A while ago I submitted a PR to the ngOfficeUIFabric project to add support for those who had Wallaby.js installed in their editor. If you don’t have Wallaby.js, it has zero effect on your code. Let’s see what it looks like.
Install & License Wallaby.js
You first have to install the Wallaby.js extension for your editor (here it is for VS Code). You can grab a trial by installing the commercial version… it will work just like the licensed version for 30 days. During the trial you’ll notice that Wallaby.js will nag you to get a license and will stop running, forcing you to restart your editor to keep using the trial. After 30 days… you really need to make the call to your boss or whip out your own credit card.
Once installed, you need to configure Wallaby.js. This is done by adding a configuration file,
Creating the configuration file is not hard… it’s quite simple. It can get complex though if you have a unique test harness configuration with module loaders and frameworks you rely on as we do in the ngOfficeUIFabric project. You can take a look at ours here: wallaby.config.ts.
The Wallaby.js site has good docs on explaining how to create your configuration file. If you are interested, you can do what we did and write yours in TypeScript. I created a type definition that’s available in the Definitely Typed registry that includes links in the comments to the docs on the Wallaby.js site if you need more help.
With that, you’re ready to let Wallaby.js do its magic!
Let Wallaby.js Run Your Tests for You!
With the configuration setup, it’s time to startup Wallaby.js. Open the command pallet in VSCode and gain and select the option Wallaby.js: Run Project Tests (there’s also a shortcut key for this). After a moment you’ll see little indicators that your tests have been run and either pass or fail. This is indicated in two ways:
- In your test file, a colored icon shows in the gutter showing if the test passed / failed.
- In you source file, a colored icon shows in the gutter showing that the code was covered by a passing / failing test.
What’s cool about it is that you can see the results of the tests running straight away… and they get rerun every time you make a change and save it either in the source code or in your tests. If you have the autosave setup in your editor, that means just a slight pause will cause your tests to get rerun. So cool!
Check it out… in this video below I’ll open the icon directive and it’s associated test file. You’ll see me start Wallaby.js from the command pallet. Notice in the gutter at the bottom, Wallaby.js is running. Because of the size of our project, it takes a second the first time it runs. Everything will pass. But then watch as a highlight a specific test and do something to break it. You’ll see the indicators change from green to red as will the results in the gutter. But what’s also slick is notice in the test file, Wallaby.js writes to the screen the failing test message… way cool!
Before the video I already opened the ngOfficeUIFabric project, build the entire project (
How Wallaby.js Works
When working through the configuration file, I found it helps to understand a bit more about what’s going on and how Wallaby.js works. Had I known how it works, it would have helped me a bit more in understanding how to customize the config.
Behind the scenes, Wallaby.js is copying the SUT (system under test) code that you define in the config as well as the test code to a temporary location. It then runs through its pre & post processors, finally running your tests. It takes the metadata returned by the test utilities to decorate the code in the editor.comments powered by Disqus