It has been surprisingly hard to find a very simple tutorial to get started with Express, along with some common helpful tools, including tests!

Here’s a little tutorial for Node.js v0.10 and Express 4. I’m learning Express, since I’m working on an app in SailsJS, so I will pick options that mirror choices made by the SailsJS framework.

Install Express

Express is a popular simple web app framework for Node (similar to Sinatra for Ruby), and is easily instally with the fabulous Node Package Manager, npm. I find the generators to be handy (at least for learning) and don’t ship with Express anymore, so you need to install them separately.

npm install -g express
npm install -g express-generator

Create an Express App

Let’s create an app named ‘test-app’ — this will create a new directory of that name with all the app files in it.

express test-app -e

The -e option tells express-generator to use ejs. (From the Express guide: Jade is the default. Express-generator supports only a few template engines, whereas Express itself supports virtually any template engine built for node. For the complete list, see express --help

It shows you all the files it creates and even gives a hint about next steps:

cd test-app
npm install

npm install will download all of the dependencies specified in our “package.json” file and put them in the the node_modules directory. This directory will get big fast, so we probably want to add to .gitignore.

Run the App!

Start the server

npm start

Then go to http://localhost:3000/ and see:
Browser with URL http://localhost:3000 shows Express in large letters, smaller letters below display "Welcome to Express"

Stop the server with ctrl-C.

Take a moment to review the contents of the generated package.json, the npm docs are a good reference for the defaults. All of the dependencies that we have right now are ones that express decided we should have. Max Ogden has some nice docs about Node modules.

Add a “devDependency” section to package.json:

  "devDependencies": {
    "mocha": "*",
    "chai": "*",
    "supertest": "*",
    "supervisor": "*"

We’re adding a set of tools that are installed with npm but only used for development and testing.

Don’t forget to add a comma or we’ll get a scary looking error:

npm ERR! install Couldn't read dependencies
npm ERR! Failed to parse json
npm ERR! Unexpected string

Also in “package.json,” change

  "scripts": {
    "start": "node ./bin/www"


  "scripts": {
    "start": "supervisor ./bin/www",
    "test": "./node_modules/.bin/mocha"

the install the new packages with:

npm install

We’ve just added a set of development tools for rapid iteration and testing. The scripts section lets us create shortcuts for the npm command.

Supervisor Allows Fast Experimentation

Supervisor makes it so you can edit files and just refresh the page to see the change. Now that we have edited the npm ‘start’ script to use supervisor, we can:

npm start

We can view the main index page, by going to http://localhost:3000. Then without stopping the server, let’s edit


so the H1 text says “Hello!” instead of Express. We can refresh the page to see the update.

Mocha, Chai and Supertest for Testing

Mocha will serially run a set of tests and report failures nicely. It supports a number of different assertion libraries. Chai is a single assertion library that supports the popular variants: assert, expect and should.

You’ll need to create a test directory, empty for now. Let’s make sure we’re set up right:

mkdir test
npm test

We should see:

  0 passing (2ms)

create the file


with a test

var request = require('supertest')
  , express = require('express');
var app = require('../app');
describe('Index Page', function() {
  it("renders successfully", function(done) {
    request(app).get('/').expect(200, done);    

run the test with

npm test

and it passes!

Adding New Behavior Test First

We can add expectations to our test. Let’s plan to add the text “Hello World to the index page. Supertest supports simple regex syntax for comparing text. The super test API cleverly supports concise testing by assuming a number as the first param is a status code, but a regex or a string wants to compare to the body.

  it("renders successfully", function(done) {
      .expect(/Hello World/, done);    

This will fail

  1) Index Page renders successfully:
     Error: expected body '\n\n  \n    Express\n    \n  \n  \n    <h1>Hello!</h1>\n    

Welcome to Express

\n \n\n' to match /Hello World/

Now we can edit the page in


and run the test again with

npm test

to see it pass!

  Index Page
GET / 200 10ms - 211b
    ✓ renders successfully 

  1 passing (34ms)

The project I’m working on, Midas Innovation Toolkit, was developed in the open from day one. It started as a Presidential Innovation Fellows project, sponsored by the US Department of State.

Both the State Dept and Health and Human Services (HHS) are actively working to pilot the software within each agency to foster collaboration within different target communities. Developers at each agency are leveraging each other’s efforts by submitting changes (via pull requests) to a common shared codebase (hosted on github).

It’s exciting to see this cross-agency collaboration through open source. The software is designed to help agency employees collaborate across team boundaries, and it’s wonderful that we’re doing that with the software itself using the entirely different mechanisms of open source.

I’m relatively new to the project and still learning about it myself, but would welcome volunteer contributions — or feedback on how to make the project more welcoming to people who want to help. It uses Nodejs and Sails with Backbone on the front end, and we’ve just started writing some Chef recipes for automated deployment. There’s a lot of low-hanging fruit in the github issues list.

Would love to hear what you think about this project specifically or government open source in general!

update: follow the rspec upgrade guide and try the transpec gem

Upgrading a Rails app to RSpec 3, I appreciated Jake Boxer’s guide. However, his regular expressions didn’t work in the editors I use, so I whipped up some command-line options that use the flexible unix utility sed.

If you want to actually understand the following scripts, I recommend Bruce Barnett’s sed tutorial and remember xargs is your friend.

Also, there are a few differences with sed on OSX, so these may not work on other platforms.

I didn’t attempt to handle multi-lined expressions, so I searched my spec directory for “lambda” in advance and changed those manually, and, of course, found a few other exceptions by running my tests afterwards.

Change “should ==” to “should eq”

You’ll need to change other operators also, but this was a pattern that happened to be very common in my code.

find . -type f -print0 | xargs -0 sed -i "" -E "s/^([[:space:]]+)(.*)\.should ==[:space]*(.*)[:space]*$/\1\2.should eq(\3)/g"

Change “whatever.should” to “expect(whatever).to”

This also works for should_not, since it is okay to say .to_not, even though I usually see people wrote .not_to

find . -type f -print0 | xargs -0 sed -i "" -E "s/^([[:space:]]+)(.*)\.should/\1expect(\2).to/g"

Also, check out: Cyrus Stoller’s upgrade tips