The JavaScript blog.


sponsored-content build-tools build-systems wallaby.js testing build

Wallaby.js, Brunch

Posted on .


Wallaby.js, the continuous test runner that outputs results directly into your editor, currently has a 20% discount on IntelliJ Platform licenses until 7th of June 2015. There are also free betas available for Visual Studio, which usually costs $100 for a single license or $160 for a company seat license.

Wallaby.js for Visual Studio is new, and it supports code coverage, smart actions, and it has font and colour options. This is what it looks like:

Wallaby in VS

In that screenshot the green squares means that the source is covered by at least one test, and the pink square means the source is on the execution path of a failing test. The blog post on Visual Studio has more details and gifs for each feature.

In other Wallaby.js related news, it's recently got support for the Facebook Jest testing framework (which I've been using with React projects). You can find an example in wallaby-jest-sample.

Finally, Artem Govorov, who works on Wallaby.js, has been writing interesting posts about JavaScript testing on his blog. Check out Heroes of JavaScript and Testing for an amusing (but useful) overview of testing in JavaScript.


If you're not entirely happy with Gulp and Grunt, did you know there's an older build system called Brunch? It's installable with npm (npm install -g brunch), and the people behind it have created a new guide that makes it easy to get started.

Brunch is not a task runner. Gulp and Grunt are generalised task runners, and one of the reasons they exist is not everyone can run JavaScript programs can easily run a makefile. I really like using makefiles for Node projects, but Windows web developers often complain that they don't have make installed, or don't want to install it. Another reason to use Gulp or Grunt is they can provide higher-level abstractions that make reading and writing tasks easier for web developers.

So why is Brunch not a task runner? Well, it's a purely focused on asset-building. It knows about JavaScript and CSS, and can handle incremental building and smart concatenation of these files. I recently spent a good two hours combining Watchify and Browserify in a Gulp task to get incremental builds working for a React/Browserify project, but if I'd have used Brunch I could have just run brunch watch --server.

Using Brunch with an existing project might have been as much work as my Gulp/Watchify/Browserify task -- I haven't yet tried using Brunch with a big and established (OK, messy) project. I have, however, tried creating a Brunch skeleton to see what a Brunch-built project looks like, and it seems pretty good to me. If you find Gulp and Grunt hard to use then try a Brunch skeleton and take a look at the new Brunch guide.


tutorials testing angularjs error-handling

AngularJS Form Errors, Angular Integration Tests

Posted on .

AngularJS: API Error Code Handling in Forms

When you're writing forms with Angular, it's not always clear how to handle errors in a reusable way. For example, what format should the server use to send back structured error message to the client? How do you use these responses to annotate fields with errors?

Szymon Kosno sent in AngularJS: API Error Code Handling in Forms, a tutorial that shows how to use error handling without explicit error handling in view controllers. It makes suggestions for how to structure detailed JSON error responses, and how to support different types of errors: for example, global errors and errors for specific form fields.

The form's markup uses an api-validate directive for input elements that should be validated by the server and will show error annotations. This allows the underlying error handling code to determine that the field is API error aware, so errors can be displayed or hidden as required.

With the right directives and services, Szymon is able to remove custom error handling code, which really cleans up the associated controllers. This article is useful if you've ever been confused about how to handle server-side errors, which you should always do for security and sanity.

Angular Integration Tests

Torgeir Helgevold sent in Angular integration tests, which gives some background to integration tests and includes a detailed example towards the end of the article.

In the following example I will demonstrate how to test a series of nested components with shared state. My sample code includes a parent directive where a user can add an inputed number to a list by clicking a button. Nested within there are two directives, one for calculating the sum of all items, and a second directive for building a comma separated string from the items in the list.

The example uses Angular's controllerAs syntax to simulate isolated scopes and pass changes. If you've ever used something like Selenium for integration tests, then you might want to compare Torgeir's approach if you're looking for something more lightweight and focused.


frameworks libraries v8 node testing rest modules

Node Roundup: io.js 2.0, Bootstruct, JSVerify

Posted on .

io.js 2.0

io.js 2.0 was released this week, and it brings some big changes from V8 and fixes to core modules.

The V8 changes include the class keyword in strict mode without flags, shorthand method and property syntax, rest parameters (with --harmony-rest-parameters), computed property names (with --harmony-computed-property-names), and unicode escapes (with --harmony_unicode and --harmony_unicode_regexps). "Rest parameters" means function(a, b, ...args) {}, and args is actually a real array. MDN has more details.

Unfortunately this release has breaking changes, so you'll want to test it thoroughly. The breaking changes are partly related to V8 because the C++ API has changed. I think this might impact some native modules, but I haven't checked the details. The behaviour of os.tmpdir has changed as well, it no longer returns a path with a trailing slash.


Bootstruct (GitHub: taitulism/Bootstruct, License: ISC, npm: bootstruct) by Taitu Lizenbaum is a module for creating RESTful frameworks based on files and folders. If you create a file in a folder called post, it will map the methods inside to POST requests.

To write methods, you have to create functions that take a single argument: io. This value has res and req objects, so it looks similar to other Node HTTP frameworks.

The readme has a lot of details on how Bootstruct generates the internal representation of the folders, filenames, and HTTP verbs, and it seems like it would be fairly easy to get used to the pattern. If you consider app.httpVerb to be unnecessary boilerplate, or perhaps have folders of data that you could map to a Bootstruct application with suitable wrapping code, then you might find it useful.



I'll admit that I was a little bit confused by JSVerify (GitHub: jsverify/jsverify, License: MIT, npm: jsverify). It's a "property-based" testing framework, which to my JavaScript-oriented mind interpreted as something that tests properties on objects. Property-based testing actually refers to a style of testing where properties are specifications of a behaviour that should hold certain values. I found a nice and short definition of it by Jessica Kerr:

Property-based tests make statements about the output of your code based on the input, and these statements are verified for many different possible inputs.

JSVerify will generate inputs for a function. This example is taken from the documentation:

// forall (f: json -> bool, b: bool), f (f (f b)) ≡ f(b).
var boolFnAppliedThrice =  
  jsc.forall('bool -> bool', 'bool', function(f, b) {
    return f(f(f(b))) === f(b);

// OK, passed 100 tests

It also includes examples for testing promises. The way it works with JavaScript's syntax and the compatibility with asynchronous code makes the tests look very succinct, but it will take a bit of practice to get the hang of it.


testing rest ES6 sponsored-content coverage

Wallaby.js Updates, Jasmine ES6 Tests, Chakram

Posted on .

Wallaby.js Updates

I recently wrote about Wallaby.js, and the authors have just released a major update that adds support for ES7, RequireJS, Browserify, and webpack. I'm a fan of Browserify so I was excited to see this -- you can get it at hwallabyjs/wallabify. The webpack postprocessor is available here: jeffling/wallaby-webpack.

Other updates include the news that a full-time developer has joined the project, and a tutorial that introduces the idea of live editing with testing.

Wallaby.js is an intelligent test runner for JavaScript projects, and has some cool features like editor-integrated code coverage reporting, and parallel test execution. It supports React JSX, popular test frameworks like Jasmine and Mocha, and even works with TypeScript and CoffeeScript.

Wallaby.js is a commercial product, but it's currently free during the preview. The site has more details on how to sign up for the preview: http://wallabyjs.com/.

Jasmine ES6 Tests

We're used to using transpilers for client-side code and sometimes Node projects, but what about tests? If ES6 really makes code more readable and maintainable, then I definitely want to use these language features to make my tests better! Torgeir Helgevold sent in a tutorial about writing Jasmine tests with ES6. The basic idea is to add preprocessors to a karma.config.js file that includes settings for Babel.

Karma is the test runner used by AngularJS, and it's test framework agnostic, so you could adapt this technique to work with Mocha as well.

Because Karma can easily be used to manipulate your test files before they execute, then it makes sense for people who want to use transpilers. I haven't done this before (my tests are usually very vanilla Mocha/assert tests), but it seems like a reasonable solution.

Chakram API Testing

Chakram (GitHub: dareid/chakram, License: MIT, npm: chakram) by Dan Reid is an API testing framework, based on promises. It includes Mocha and Chai, but instead of calling done callbacks you can use the wait method:

var chakram = require('chakram');  
var expect = chakram.expect;

describe('Minimal example', function() {  
  it('should provide a simple async testing framework', function() {
    var request = chakram.get('http://httpbin.org/get');
    return chakram.wait();

There's a list of extended chai expectations, and methods for HTTP and promises in the Chakram module documentation. This includes methods for HTTP verbs, so you can do chakram.patch and chakram.put.


libraries testing node modules

Selenium and Node.js, fourk.js

Posted on .

Using Selenium and Node.js for Testing

David Posin sent in an article about using a Node server to control the Selenium process, so the test runner is interactive:

It occurred to me I could help alleviate this by having the browsers at the ready and eagerly waiting for the command to start testing.

I type a command into the console of my running Node server, and it instructs the already open browsers to run the tests. I like this approach because I can build my tests a little bit at a time and confirm they are working as I go. This is all possible because of the web driver component, which includes a JavaScript API, created by the Selenium team.

The script is included in the post. It works by using Node's child_process module to spawn a script with the Selenium browser session ID.

I've noticed a lot of people struggle to get solid and reliable full-stack tests working, so if you've been looking for a better Selenium workflow then this might help.


fourk.js (GitHub: crcn/fourk.js, License: MIT, npm: fourk) by Craig Condon has an API that's like clusterjs but for forking web workers in a browser:

var cluster = require('fourk');

if (cluster.isMaster) {  
  for (var i = 4; i--;) cluster.fork()
} else {
  // do stuff as worker

The cluster object uses EventEmitter, so you can emit messages to workers, and listen with on or once. This will definitely appeal to Browserify front-end developers who want web workers.