Archive for the ‘ Posts ’ Category

Auto-loading test fixtures in node

Something which comes back time and again is the loading of test fixtures for my unit tests. This may involve a lot of boilerplate in my test files; a bunch of requires or fs.readFiles. There is however a very easy fix by using the splendid require-directory module.

As the description of the project says it …

recursively iterates over specified directory, requiring each file, and returning a nested hash structure containing those libraries.

I.e. it takes a directory, traverses its subdirectories and reads all of the files they contain and maps them to an object with the filenames as keys.

Tutorial files

I created a tutorial project with the completed files. The tutorial project already contains all dependency declarations, all you need to do is clone the repo and

$ npm install

when in the cloned repo directory.

Starting from scratch

However, if you’re starting from scratch you’ll need to install the require-directory module into your project first:

$ npm install require-directory

There are many projects with similar names, make sure you use require-directory, since that’s the one I’m interested in. Yeah, it’s a bit confusing that the project is named differently on github.

Let’s get started

Now let’s use it to load our fixtures.

For example if we got the following fixtures directory structure:

Accessing the fixtures

What we want is to be able to load all of these files into our tests at once and access them through an object.

E.g. in our tests we want to access the contents of foo/bar.json like this:

    test.deepEqual( main.awesome(), );

with fixtures being the object containing all of the loaded files.

Exposing the fixtures

In order to do this we need to create a fixtures/index.js file which uses node-require to load the files and exports them as an object. Like this:

//file: fixtures/index.js
var requireDirectory = require('require-directory');
module.exports = requireDirectory(module);

This file needs to reside at the root of the fixtures directory.

Using the fixtures

In our test file now we can require the fixtures directory itself:

var fixtures = require('./fixtures');

Et voila, you’re done: the fixtures object contains all files and their contents.

The full code of our test file:

'use strict';

var main = require( '../lib/main.js' );
var fixtures = require( './fixtures' );

exports.tutorialLoadFixtures = {
  'awesome' : function( test ){
    test.expect( 1 );
    test.deepEqual( main.awesome(),, 'should be "value: Awesome!"' );

Easy, isn’t it? Take a look at the tutorial project to see all the files.

Be sure to keep an eye on my blog next week, since I’ll be reviewing the “Getting started with Grunt” book by Packt!

Best way to handle large grunt files

I love Grunt. Each project I’ve done last year I’ve used it to automate linting, building, testing, etc. There’s just one thing which keeps on bothering me: once a project grows, so does the grunt file. I just keep on finding new grunt plugins and adding them to my projects. With every plugin, task configuration and declarations are added to the Grunt file and its size just keeps on growing, making it very messy and hard to maintain IMO.

TL;WR (too long;won’t read)

We’re having a discussion on the best way to manage large grunt files in this thread of the yeoman generator-webapp project. Let us know what you think!

So, what’s it all about?

To me, the best way to manage grunt task configurations is by splitting it all up into several files.

I wrote a module load-grunt-configs which loads your grunt task configuration objects from files in a directory.
Continue reading

Load #gruntjs task configurations from separate files.

Grunt files tend to grow fast due to big amount of tasks and their configuration objects. I created a module load-grunt-configs that allows you to split your Grunt task configuration objects into separate files any way you choose. There are similar modules that allow you to the same, but with grunt-load-configs you can configure targets for a single task in multiple files.

This means you no longer need to group all task targets into a single file, but can split them up according to their task dependencies.

See for examples and usage.

Continue reading

Grunt-generate: a Grunt task to generate files from user-defined templates

Grunt task that generates files from user-defined templates. It follows the DFGIMW mantra (don’t fucking get in my way).

Continue reading

#Robotlegs 2 Beta 6 released

Yesterday we released Beta 6 of Robotlegs 2. Behind the scenes lots of improvements were made, aimed primarily at extension developers. But we also reintroduced some things and added a few minor functionalities:

Direct Command Map

The Direct Command Map allows you to execute commands directly and to pin and release commands in/from memory.
Continue reading

#Robotlegs 2 – we’re working on it. It’s coming.

First of all I’m real happy and proud to announce that I joined the Robotlegs team a few weeks ago.
I’ve loved RL from the first moment I started working with it and that hasn’t changed over the years, so it’s really exciting to me to be a part of it now.

And… It’s coming. The official version 2.
No date.
But it is coming.
Continue reading

#dijonjs demo included in todomvc labs section

Last week my demo for Dijon (an IOC/DI javascript framework I created) was included in the labs section of TodoMVC, a hugely popular common learning application for JavaScript MV* frameworks.

So what does it do?

In the demo Dijon is used on top of JQuery to provide structure and dependency injection for the app. It allows you to decouple several functional units and let them work together and communicate.

Even though Dijon does not impose a typical MV* structure in any way, it allows you to easily do so w/o forcing you to use any specific paradigm.

Continue reading

%d bloggers like this: