Sublime build systems and Mocha.js

Keeping your projects well organised and tested can bring some cool benefits besides the obvious often referred in the books. One I am really fond of is defining a uniform test structure in par with the source code. Something simple like:


.. and then adapt my Sublime editor to run my Mocha.js tests for the file I am currently working on. This is no big news and you can find documentation around the web in order to do it.

Atom already provides a better context test runner!

That might be true, but with little extra work you can make Sublime outperform Atom easily. To do that we need to add a build system.

Setting everything up

To start off you need to navigate to ToolsBuild SystemNew Build System…. A new tab will open and now we are ready to start our configuration. Here’s a basic build system:

  "cmd": ["mocha"],
  "working_dir": "${project_path:${folder}}"

As you can see it’s nothing more than a JSON file with some configurations. The cmd property is the command it will be run on the specified working_dir. Neat right? You can use this for pretty much anything: running tests, running deployment scripts, git commands and so forth.

So how can we wrap up a nice build system to run the specific tests of the file we are currently working on? To do that we need to understand some other features Sublime offers us. We can add to our previous build system the following:

  "cmd": ["mocha", "${file}"],
  "working_dir": "${project_path:${folder}}"

This will now run mocha on the the current file opened in the editor.

We are getting there but we are not quite there yet. Imagine we are working on src/index.js and we want to run the tests related to our file which are located in test/index_test.js. We need a way to relate our files but in fact that’s already done, notice we can use the pattern filename_test.js to do that. As such we can create a small script file with the commands we want to run via Sublime, instead of just running them directly from the build system.

I’ll just go ahead and present a simple makefile which will do that for us:

ifeq ($(findstring _test.js,$(REPORTER_FILE)),_test.js)
	@mocha --bail $(REPORTER)
	@find test -name $(subst .js,_test.js,$(REPORTER_FILE)) | xargs mocha

.PHONY: test

As you can see we have a simple conditional checking what type file we reported back to the makefile. If the file contains already our test pattern, run mocha directly on it (the –bail flag is optional, it just stops testing if one of the test fails). Otherwise find our test files and run mocha on it.

Finally we adapt our build system:

  "cmd": ["make", "REPORTER=${file}", "REPORTER_FILE=${file_name}"],
  "working_dir": "${project_path:${folder}}"

And BAM with just a CMD + B the console panel will come up on Sublime and run the tests related to your current working file.

More tricks

The great thing about keeping a build like this is that there’s even more you can do with Mocha. For example you can create a pattern on each test file for a specific test to run and use the –grep option from Mocha to run tests matching that pattern instead of running all tests in the file. Or go even deeper by using –fgrep and only run the tests matching a specific string.

These are all tips for being a bit more productive and an extra reason for everyone to make the world a better place and try Test Driven Development. There’s nothing more comfortable than developing with a nicely organized test suite!


NOTE: If for some reason your node modules are not tied to your $PATH you can also add another property to your build system called “path”: “path_here”.


1 – Sublime build systems

2 – Sublime test runner

3 – Mocha js

By |October 4th, 2015|Categories: ALL|

About the Author:'
Software engineer passionate about the web and mobile technologies. On my free time I usually read, code and travel.