Read Building a Web App Guided By Tests

Building a Web App Guided By Tests

Greg Stewart

Introduction
Getting started
- Setting up our project
- Recap
Writing our first functional test
Continuous delivery
Refactoring our build file
- Extending our build file by linting our code
- Recap
Building our assets
- Compile our less to css
- Concatenate and minify our JavaScript
Unit tests

Introduction

The idea for this book started with a series of blog posts I wrote some time ago exploring building a Backbone.js app using tests. I initially wanted to just consolidate these blog posts into a book, however once I started jotting down what I wanted to put into this series, I decided there was more to write about.

In the Front end and JavaScript world we have come a long way since the heady days of table based layouts sprinkled with Macromedia roll over scripts to make web pages interactive. The lines between back end and front end application code has almost blurred completely, you could argue it no longer exists when you consider Isomorpic apps. Our tooling has changed substantially as well: at our disposal we have package managers (for both back and front end), build tools, unit test frameworks and deployment tools.

Conventions

Before we get started here are few conventions to be aware of. Where ever you see a statement like below starting with > this is a command you type from the terminal window

1 > menaing a command typed at the console

Whereas as the following typicallys is code or a configuration to be added to a file:

code
or
config

What we will be building

Over the coming pages and posts we will explore how to build a web app guided by tests, using a toolset that will allow you to deploy with each commit to the cloud. We’ll making use of JavaScript across the whole stack to build a small weather app using forecast.io’s API. The app itself will use the browser’s Geolocation API to figure out where your user is and retrieve a weekly weather forecast for that location.

How we will build it

Plain and simple, we’ll build this app guided by tests, using a continuous delivery model and have it deployed using Codeship’s CD service to a Heroku instance.

The focus of this book is really about setting you on the right path to delivering quality software reliably and continuously. By the end you should have the confidence to push every commit to ‘production’.

We will be making extensive use of the following tools:

Node.js
Grunt
Karma
Jasmine
Cucumber
Selenium

What you will need

There are few pre-requisits you will need to get this app built. You will need to sign up for some services, grab a code/etxt editor, set up a version control system and finally get your Node.js environment configured.

As I mentioned for our weather forecast API, we’ll be using forecast.io, so you might want to go and sign up for a developer account as you will need a key to access the API.

You should also sign up for a Github or Bitbucket account if you don’t already have one, we’ll need this for version control and our CI service.

So that we can reliably deploy our app, we’ll make use of Codeship’s hosted Continuous Integration service. Sign up for the free service to get started.

To host our app we’ll make use of Heroku’s cloud computing service. They also offer a free service to help you get started.

That should cover the things you need to sign up for.

Code editor

You will need a decent IDE (I recommend WebStorm) or Text Editor (Sublime is very popular with many of my co-workers).

Cloud9’s browser based editor (though calling it just an editor, is doing it a bit of a disservice) Is another option I can recommend.

Version control: Git

Using Version Control for every project is a must, regardless of size or complexity. If you don’t already have Git installed you should do so. There are many ways to install the necessary binaries and the Git website has all the necessary links. If you are on a Mac though, then I would recommend using Homebrew to install the binaries.

If you are new to Git then I recommend taking the Git Immersion guided tour.

Node.js and NPM

We’ll be making extensive use of JavaScript and various libraries throughout the book, so you will need to install Node.js and NPM. Once again if you are on a Mac though, then I would recommend using Homebrew to install the binaries.

NPM will allow us to resolve all of the dependencies we need in order to achieve our goal of building and delivering a web app guided by tests.

Bower

Bower is handy tool to manage your front end library dependencies, so I recommed installing it as well.

Grunt

Grunt will be our build and automation tool. If you haven’t used Grunt before, be sure to check out the Getting Started guide, as it explains how to create a Gruntfile as well as install and use Grunt plugins.

With all that installed and configured, it’s time to get started!

Getting started

The first thing I like to do with any project is to get our build pipeline set up and start deploying code to our ‘production’ environment. To that end we need to look at building the simplest thing possible to validate our testing infrastructure works, our CI envinronment can pick up changes on commit and after a succesful build deploy the changes.

I will assume you have signed up and installed all of the software outlined in the What you will need section.

Setting up our project

Open up a terminal window and navigate to the location you want to store your project files.

I use a mac, so most of the commands listed here are *nix based and for the most part they shouls also work on a windows machine.

Once there let’s create a project folder and change into it:

1 > mkdir weatherly && cd weatherly

Let’s initilise our github repository:

> git init
> Initialized empty Git repository in /Users/gregstewart/Projects/github/weather\
ly/.git/

Before we go any further let’s create a .gitignore file in the root of our project and add the following lines to it:

1 node_modules
2 .idea

Once down let’s commit this change quickly:

1 > git add .gitignore
2 > git commit -m "Adding folders to the ignore list"

From a folder perspective I like to create a distribution folder and an app folder to hold the source, so let’s go ahead and add these folders as well.

1 > mkdir app
2 > mkdir dist

We’ll start by using bower to grab some of our front end dependencies. Let’s start by creating a bower.json file by typing bower init, fill in the details as you see fit, but here’s what I selected:

{
name: 'weatherly',
version: '0.0.0',
authors: [
	'Greg Stewart <gregs@tcias.co.uk>'	
],
description: 'Building a web app guided by tests',
moduleType: [
	'commonjs'
],
license: 'MIT',
homepage: 'http://www.tcias.co.uk/',	
private: true,
ignore: [
	'**/.*',
	'node_modules',
	'bower_components',
	'test',
	'tests'
]
}	

Everybody likes a bit of Bootstrap so let’s start with that package :

1 > bower install bootstrap --save

The --save flag at the end of the command means that the dependecy will be added to our bower.jon file during the installation of the package. We are doing this because we do not want to check in any external dependencies into our repository, instead at build/CI time we’ll restore these using bower.

So let’s edit our .gitignore file to make sure we don’t accidentally commit these files:

node_modules
.idea
bower_components

And let’s add this change to our repo:

1 > git add .gitignore 
2 > git commit -m "Adding bower_components to the ignore list"

To round things off let’s install HTML5 boilerplate

1 > bower install html5-boilerplate

You may have noticed that I decided not to add this package to our bower.json file, simply because we’ll copy the files we need into our app folder:

> mv bower_components/html5-boilerplate/css app/
> mv bower_components/html5-boilerplate/img app/
> mv bower_components/html5-boilerplate/*.html app/
> mv bower_components/html5-boilerplate/*.png app/ 
> mv bower_components/html5-boilerplate/*.xml app/
> mv bower_components/html5-boilerplate/*.ico app/
> mv bower_components/html5-boilerplate/*.txt app/

In your editor of choice open up the app/index.html file and add the following:

<!DOCTYPE html>
<!--[if lt IE 7]>      <html class="no-js lt-ie9 lt-ie8 lt-ie7"> <![endif]-->
<!--[if IE 7]>         <html class="no-js lt-ie9 lt-ie8"> <![endif]-->
<!--[if IE 8]>         <html class="no-js lt-ie9"> <![endif]-->
<!--[if gt IE 8]><!--> <html class="no-js"> <!--<![endif]-->
<head>
   	<meta charset="utf-8">
   	<meta http-equiv="X-UA-Compatible" content="IE=edge">
   	<title>Weatherly - Forecast for London</title>
   	<meta name="description" content="">
    <meta name="viewport" content="width=device-width, initial-scale=1">

       <!-- Place favicon.ico and apple-touch-icon.png in the root directory -->

   	<link rel="stylesheet" href="css/main.css">
</head>
<body>
   	<!--[if lt IE 7]>
       	<p class="browsehappy">You are using an <strong>outdated</strong> brows\
er. Please <a href="http://browsehappy.com/">upgrade your browser</a> to improve\
your experience.</p>
   	<![endif]-->

   	<!-- Add your site or application content here -->
   	<div class="container">
       	<div class="header">
           	<ul class="nav nav-pills pull-right">
               	<li class="active"><a href="#">Home</a></li>
               	<li><a href="#">About</a></li>
              		<li><a href="#">Contact</a></li>
           	</ul>
           	<h3 class="text-muted">test</h3>
       	</div>

       	<div class="jumbotron">
           	<h1>London Right Now</h1>
           	<p class="temperature">14 degrees</p>
           	<p>Mostly cloudy - feels like 14 degrees</p>
       	</div>

       	<div class="row marketing">
           	<div class="col-lg-6">
               	<h4>NEXT HOUR</h4>
               	<p>Mostly cloudy for the hour.</p>

               	<h4>NEXT 24 HOURS</h4>
              		<p>Mostly cloudy until tomorrow afternoon.</p>
           	</div>
       	</div>

       	<div class="footer">
           	<p><span class="glyphicon glyphicon-heart"></span> from Weatherly</\
p>
       	</div>

   	</div>
   	<p></p>

   	<script src="//ajax.googleapis.com/ajax/libs/jquery/1.10.2/jquery.min.js"><\
/script>
   	<script>window.jQuery || document.write('<script src="js/vendor/jquery-1.10\
.2.min.js"><\/script>')</script>

   	<!-- Google Analytics: change UA-XXXXX-X to be your site's ID. -->
   	<script>
       	(function(b,o,i,l,e,r){b.GoogleAnalyticsObject=l;b[l]||(b[l]=
              	 function(){(b[l].q=b[l].q||[]).push(arguments)});b[l].l=+new Da\
te;
           	e=o.createElement(i);r=o.getElementsByTagName(i)[0];
           	e.src='//www.google-analytics.com/analytics.js';
           	r.parentNode.insertBefore(e,r)}(window,document,'script','ga'));
       	ga('create','UA-XXXXX-X');ga('send','pageview');
   	</script>
</body>
</html>

If you open up the file in your browser you should see something like this hopefully:

Rendered HTML

Not exactly something to write home about, but it’s enough for us to get started setting up our little server, writing a functional test and deploying something to our Heroku instance. We’ll make this a lot prettier later on in the book when we deal with setting up Grunt to build our JavaScript and CSS assets.

The last thing we’ll do is commit all of our changes to our local repository:

> git add .
> git commit -m "Added Bootstrap/Modernizr to bower.json, moved the skeleton of \
the HTML5 boilerplate to the app folder and created a base index page for our we\
ather forecat app."

At this stage it’s a good idea to also push the changes to our remote repository. If you have followed the What you will need section, you will hopefully have created a Github account. If not go ahead and to that now. Then create a repository called weatherly, here’s what I entered:

Creating your weatherly repository

To push our changes to the remote repository, you will need to tell your local repository where it is (be sure to replace the <account_name> with your actual account name):</account_name>

1 > git remote add origin https://github.com/<account_name>/weatherly.git

Now you can push your changes:

1 > git push -u origin master

Recap

Before we move on let’s just quickly recap what we have done so far:

created our app folder structure
initialised our git repo
created a Git ignore file
used bower to manage some of our front end dependencies:
- Bootstrap
- Modernizr
- HTML5 boilerplate
created a very basic index.html page
pushed all of the changes to our remote git repository

Writing our first functional test

__TODO I seem to mainly refer to the tests as end to end test, I should rename this section to reflect this __

What is a functional test? Wikipedia tells us:

Functional testing is a quality assurance (QA) process[1] and a type of black box testing that bases its test cases on the specifications of the software component under test. Functions are tested by feeding them input and examining the output, and internal program structure is rarely considered (not like in white-box testing).[2] Functional Testing usually describes what the system does.

Throughout this section and in future you may find me refering to these kind of tests as Functional Tests, End-to-end, Feature tests or indeed User Journey tests. Confusing I know, I will try my best to keep it to feature and end-to-end tests, but be prepared when discussing this topic to come across the same variety of breadth of names for Functional tests.

With the definition out of the way, let’s go through the steps necessary in order to write our first functional test. We needed a test page, which we built in the previous section, now let’s set up a simple Node.js webserver to host the page.

Web server: Express

A good practice to follow while working with Git is to create a branch for each feature that you are working on, so let’s go ahead and create a new branch for this item of work.

1 > git checkout -b web-server

Make sure you are in the root of our project and not in the app/ folder

Since we’ll be using Node.js we can use NPM to manage the dependencies. These dependencies are stored in a folder called node_modules. Since we don’t want to check any node modules/packages into our repository we added that folder to our .gitignore file in when we first set up the project. If we don’t add those packages to our repository you may be wondering how our CI and Heroku instance will now how to run the app. To that end we’ll use a handy file called package.json. When we run NPM we can not only install dependencies, we can also add them to our package.json file and our target envinronments can read this file and install these packages for us.

Typing npm init allows us to create our package.json, here’s what I answered when prompted:

This utility will walk you through creating a package.json file.
It only covers the most common items, and tries to guess sane defaults.

See `npm help json` for definitive documentation on these fields
and exactly what they do.

Use `npm install <pkg> --save` afterwards to install a package and
save it as a dependency in the package.json file.

Press ^C at any time to quit.
name: (weatherly)
version: (0.0.0)
description: Building a web app guided by tests
entry point: (index.js)
test command: grunt test
git repository: (https://github.com/gregstewart/weatherly.git)
keywords:
author: Greg Stewart
license: (ISC) MIT
About to write to /Users/gregstewart/Projects/github/weatherly/package.json:

{
"name": "weatherly",
"version": "0.0.0",
"description": "Building a web app guided by tests",
"main": "index.js",
"scripts": {
	"test": "grunt test"
},
"repository": {
	"type": "git",
	"url": "https://github.com/gregstewart/weatherly.git"
},
"author": "Greg Stewart",
"license": "MIT",
"bugs": {
	"url": "https://github.com/gregstewart/weatherly/issues"
},
 	"homepage": "https://github.com/gregstewart/weatherly"
}

Is this ok? (yes) yes

As you can see it autocompleted a bunch of information for you, such as the project name, version number and Git details. Let’s add that file to our repo before going any further:

1 > git add package.json
2 > git commit -m "Created package.json file"

Now let’s go ahead and install a web server module. We’ll just use express.

1 > npm install express --save

Similar to how we used Bower, by specifying --save the dependecy was added to our package.json file, if you open it up you should see the following toward the end of the file:

"dependencies": {
"express": "^4.4.5"
}

Next create a new file called server.js in the root of our project and add the following content:

var express = require('express');
var app = express();

app.use(express.static(__dirname + '/app'));

var server = app.listen(3000, function() {
 console.log('Listening on port %d', server.address().port);
});

And to start our server type:

1 > npm start

If you now open your browser and hit http://localhost:3000 you should once again see:

Rendered HTML hosted by our Connect server

The process that runs our server is not daemonised and will continue to run until we close the console or type ^C. Go ahead and kill the server. Next we add those changes to our repository, merge these changes back into master and finally push to origin:

> git add server.js
> git add package.json
> git commit -m "Installed Connect and created a very basic web server for our a\
pp"
> git checkout master
> git merge web-server
> git push

Cucumber, WebDriver and Selenium

For our functional tests I have chosen Cucumber.js and WebDriver.js with Selenium. I chose this combination because I believe this will give you greater felxibility in the long wrong, especially if you plan on using different languages in your toolchain. You can find Ruby, Java and .Net versions of Cucumber, WebDriver and Selenium.

Once again we’ll create a dedicated branch for this work:

1 > git checkout -b functional-test

Selenium

Selenium uses Java, so you will need to make sure you have it installed.

We could install the binaries manually, but since I plan using Grunt to automate tasks around starting and stopping the server, we might as well use [grunt-selenium-webdriver] (https://www.npmjs.org/package/grunt-selenium-webdriver) module as this includes everything that we need, including the jar file for the Selenium Server.

1 > npm install grunt-selenium-webdriver --save-dev

We use the --save-dev flag to indicate that we want to add this dependency to our package.json file, however only for development purposes (meaning that when we deploy to our ‘production’ environment, e.g. Heroku, it won’t install the package during deployment). With that done let’s create a Grunt task to start the Selenium server (just in case you missed it in the Getting Started section you can find more information on Grunt and tasks over at the official Grunt.js website). The first thing we’ll need is a Gruntfile.js, so add one to the root of your project and edit it to contain the following:

module.exports = function(grunt) {
'use strict';

grunt.initConfig({
});

grunt.loadNpmTasks('grunt-selenium-webdriver');

grunt.registerTask('e2e', [
	'selenium_start',
	'selenium_stop'
]);
};

Save the changes and at the command line type: grunt e2e and you should see something like this:

Running "selenium_start" task
seleniumrc webdriver ready on 127.0.0.1:4444

Running "selenium_stop" task

Done, without errors.

This told grunt to execute a task called e2e and confirms that the selenium server started properly at the following address 127.0.0.1:4444 and then was shutdown again (apparently it is not necessary to shutdown the server with a stop task).

Using Grunt to start and stop the express server

Let’s also add a step to stop and start our web server when we are running our frunctional tests. To that end we’ll install another grunt module:

1 > npm install grunt-express-server --save-dev

And we’ll edit our Grunt file so that it looks for our server.js and we can control the starting and stopping of our server:

module.exports = function(grunt) {
'use strict';

grunt.initConfig({
	express: {
 			test: {
   			options: {
     				script: './server.js'
   			}
 			}
	}
});

grunt.loadNpmTasks('grunt-express-server');
grunt.loadNpmTasks('grunt-selenium-webdriver');

grunt.registerTask('e2e', [
	'selenium_start',
	'express:test',
	'selenium_stop',
	'express:test:stop'
	]);
};

If we now run grunt e2e, we should see the following output:

Running "selenium_start" task
seleniumrc webdriver ready on 127.0.0.1:4444

Running "express:test" (express) task
Starting background Express server
Listening on port 3000

Running "selenium_stop" task

Running "express:test:stop" (express) task

WebDriver

The next thing we need to do is install WebDriver.js and we are then nearly ready to write our first feature test:

1 > npm install webdriverjs --save-dev

WebDriver is the glue between Selenium and Cucumber.

Cucumber

The final piece of the puzzle is Cucumber.js:

1 > npm install cucumber --save-dev

Our first test

Features are written using the Gherkin syntax, and this is what our first feature looks like:

Feature: Using our awesome weather app
As a user of weatherly
I should be able to see the weather information for my location

Scenario: Viewing the homepage
	Given I am on the home page
	When I view the main content area
	Then I should see the temperature for my location

I like to store these and the associated code in a e2e directory under a parent tests folder. So go ahead and create that folder structure under the root of our project. Then create a features folder and save the above feature contents to a file called using-weatherly.feature.

If we were to run our cucumber tests now using > cucumber.js tests/e2e/features/using-weatherly.feature we would see the following output:

UUU

1 scenario (1 undefined)
3 steps (3 undefined)

You can implement step definitions for undefined steps with these snippets:

this.Given(/^I am on the home page$/, function (callback) {
// express the regexp above with the code you wish you had
callback.pending();
});

this.When(/^I view the main content area$/, function (callback) {
// express the regexp above with the code you wish you had
callback.pending();
});

this.Then(/^I should see the temperature for my location$/, function (callback) {
// express the regexp above with the code you wish you had
callback.pending();
});

This is extremely useful output. While it’s clear that the code to execute the steps in the feature are undefined, the output actually gives snippets to create our step definitions. So let’s go ahead and create our step definition. Inside of our functional test folder, create a steps folder and add a file called using-weatherly-step-definitions.js with the following content:

var UsingWeatherlyStepDefinitions = function () {
'use strict';

this.Given(/^I am on the home page$/, function (callback) {
 		// express the regexp above with the code you wish you had
 		callback.pending();
});

this.When(/^I view the main content area$/, function (callback) {
 		// express the regexp above with the code you wish you had
 		callback.pending();
});

this.Then(/^I should see the temperature for my location$/, function (callback)\
{
 		// express the regexp above with the code you wish you had
 		callback.pending();
});
};

module.exports = UsingWeatherlyStepDefinitions;

Let’s try and execute our feature test again with > cucumber.js tests/e2e/features/using-weatherly.feature --require tests/e2e/steps/using-weatherly-step-definitions.js and now we should see:

P--

1 scenario (1 pending)
3 steps (1 pending, 2 skipped)

Time to flesh out the steps to do some work and check for elements on the page while the tests are running. We’ll make use of Chai.js as our assertion library, so let’s go ahead and install this module:

1 > npm install chai --save-dev

The first bit of code we’ll add to our tests is a World object, which will initialise our browser (read WebDriver) and add a few helper methods (visit and hasText). As our browser we are using PhantomJS, but if you would like to see the test running in say FireFox, simply replace browserName: 'phantomjs' with browserName: 'firefox'.

Note that other browsers such as Chrome and IE require special drivers which you can download from the Selenium website

Here’s our world object (world.js), which we save into a folder called support under tests/e2e:

'use strict';

var webdriverjs = require('webdriverjs');
/*jshint -W079 */
var expect = require('chai').expect;

var client = webdriverjs.remote({ desiredCapabilities: {browserName: 'phantomjs'\
}, logLevel: 'silent' });

client.addCommand('hasText', function (selector, text, callback) {
   this.getText(selector, function (error, result) {
       expect(result).to.have.string(text);
       callback();
   });
});

client.init();


var World = function World(callback) {
   this.browser = client;

   this.port = process.env.PORT || 3000;

   this.visit = function (url, callback) {
       this.browser.url(url, callback);
   };

   callback(); // tell Cucumber we're finished and to use 'this' as the world i\
nstance
};

exports.World = World;

Please note that if when running the tests you come across the message shown below (logging in verbose mode here), this simply (indeed simply…) means that webdriverjs cannot find phatomjs in your PATH.

================================================================================\
====
Selenium 2.0/webdriver protocol bindings implementation with helper commands in \
nodejs.
For a complete list of commands, visit http://webdriver.io/docs.html.

================================================================================\
====

[09:51:45]:  ERROR      Couldn't get a session ID - undefined
Fatal error: [init()] <=
An unknown server-side error occurred while processing the command.

Now let’s re-visit our using-weatherly-step-definitions.js and replace the contents with the following code:

var UsingWeatherlyStepDefinitions = function () {
   'use strict';

   this.World = require('../support/world.js').World;
   
   this.Given(/^I am on the home page$/, function (callback) {
     this.visit('http://localhost:' + this.port + '/', callback);
   });

   this.When(/^I view the main content area$/, function (callback) {
     this.browser.hasText('.jumbotron h1', 'London Right Now', callback);
   });

   this.Then(/^I should see the temperature for my location$/, function (callba\
ck) {
     this.browser.hasText('p.temperature', '14 degrees', callback);
   });
};

module.exports = UsingWeatherlyStepDefinitions;

The first step opens the site, and then we assert that the header element displays London Right Now and that the element with our temperature shows 14 degrees

If we were to once again try and execute our feature test, we would get an error telling us that it can’t connect to the selenium server. So let’s wrap all of this into our e2e grunt task. Let’s start by adding another module to our setup:

1 > npm install grunt-cucumber --save-dev

And let’s edit our Gruntfile.js to look like this now:

module.exports = function(grunt) {
'use strict';

grunt.initConfig({
	express: {
 			test: {
   			options: {
     				script: './server.js'
   			}
 			}
	},
	cucumberjs: {
 			src: 'tests/e2e/features/',
 			options: {
   			steps: 'tests/e2e/steps/'
 			}
	}
});

grunt.loadNpmTasks('grunt-express-server');
grunt.loadNpmTasks('grunt-selenium-webdriver');
grunt.loadNpmTasks('grunt-cucumber');

grunt.registerTask('e2e', [
	'selenium_start',
	'express:test',
	'cucumberjs',
	'selenium_stop',
	'express:test:stop'
]);
};

Now type > grunt e2e and you should see the following output:

Running "selenium_start" task
seleniumrc webdriver ready on 127.0.0.1:4444

Running "express:test" (express) task
Starting background Express server
Listening on port 3000

Running "cucumberjs:src" (cucumberjs) task
...

1 scenario (1 passed)
3 steps (3 passed)

Running "selenium_stop" task

Running "express:test:stop" (express) task
Stopping Express server

Done, without errors.

With that done we can commit our changes to our repository:

> git add .
> git commit -m "Scenario: Viewing the homepage, created and implemented"
> git checkout master
> git merge functional-test
> git push

Recap

To sum things up in this section we created a set of grunt tasks that:

start our selenium server
start our express server that hosts our page
execute the features and steps we defined with cucumberjs
output the result to the console
closes down the services after finishing the tests

We also wrote a feature test that:

open a browser
check the contents for a header
check for an element that holds the current temperature

Continuous delivery

In the previous part we wrote our first functional test (or feature test or end 2 end test) and automated the running using a set of Grunt tasks. Now we will put these tasks to good use and have our Continuous Integration server run the test with each commit to our remote repository. There are two parts two Continuous Delivery: Continuous Integration and Continuous Deployment. These two best practices were best defined in the blog post over at Treehouse, do read the article, but here’s the tl;rd:

Continuous Integration is the practice of testing each change done to your codebase automatically and as early as possible. But this paves the way for the more important process: Continuous Deployment.

Continuous Deployment follows your tests to push your changes to either a staging or production system. This makes sure a version of your code is always accessible.

In this ection we’ll focus on Continuous Integration. As always before starting we’ll create a dedicated branch for our work:

1 git checkout -b ci

Setting up our Continuous Integration environment using Codeship

In the what you will need section I suggested signing up for a few services, if you haven’t by now created an account with either Github and Codeship now is the time! Also if you haven’t already now is the time to connect your Githuib account with Codeship. You can do this by looking under your account settings for connected services:

Link your Github account to Codeship

To get started we need to create a new project:

Create a new project

This starts starts a three step process:

Connect to your source code provider
Choose your repository
Setup test commands

The first step is easy, choose the Github option, then for step two choose the weatherly repository from the list.

If you hadn’t already signed up for Github and hadn’t pushed your changes to it, then the repository won’t be showing up in the list. Link your local repository and push all changes up before continuing.

Not it’s time to set up the third step, set up out test commands. From the drop down labelled Select your technology to prepopulate basic commands choose node.js.

Next we need to tackle the section: Modify your Setup Commands. The instructions tell us that it can use the Node.js version specified in our package.json file, given that we have not added this information previously let’s go ahead and do that now. If you are unsure of the version of Node.js simply type:

1 node --version

In my case the output was 0.10.28, below is my package.json file, look for the block labelled with engines:

{
"name": "weatherly",
"version": "0.0.0",
"description": "Building a web app guided by tests",
"main": "index.js",
"engines" : {
	"node" : "~0.10.28"
},
"scripts": {
	"test": "grunt test"
},
"repository": {
	"type": "git",
	"url": "https://github.com/gregstewart/weatherly.git"
},
"author": "Greg Stewart",
"license": "MIT",	
"bugs": {
	"url": "https://github.com/gregstewart/weatherly/issues"
},
"homepage": "https://github.com/gregstewart/weatherly",
"dependencies": {
	"express": "^4.4.5"
},
"devDependencies": {
	"chai": "^1.9.1",
	"cucumber": "^0.4.0",
	"grunt": "^0.4.5",
	"grunt-cucumber": "^0.2.3",
	"grunt-express-server": "^0.4.17",
	"grunt-selenium-webdriver": "^0.2.420",
	"webdriverjs": "^1.7.1"
}
}

With that added we can edit the set up commands to look as follows:

1 npm install
2 npm install grunt-cli

Now let’s edit the Modify your Test Commands section. In the previous chapter we created a set of tasks to run our tests and wrapped them in a grunt command grunt e2e. Let’s add this command to our configuration:

1 grunt e2e

That’s hit the big save button. Right now we are ready to push some changes to our repository. Luckily we have a configuration change ready to push!

git add package.json
git commit -m "Added node version to the configuration for CI"
git checkout master
git merge ci
git push

And with that go over to your codeship dashboard and if it all went well, then you should see something like this:

First CI run!

You have to admit that setting this up was a breeze. Now we are ready to configure our Continous Deployment to Heroku.

Setting up Continous Deployment to Heroku

Before we configure our CI server to to deploy our code to Heroku on a successful build, we’ll need to create a new app through our Heroku dashboard:

Heroku dashboard

And click on the Create a new app link and complete the dialogue box.

Creating a new app

The name weatherly was already taken so I left it blank to get one assigned, if you do this as well, just be sure to make a note of it as we’ll need it shortly. I choose Europe, well because I live in Europe, so feel free to choose what ever region makes sense to you.

Confirmation screen

Armed with this information let’s head back to our project on Codeship and let’s configure our deployment. From the project settings choose the Deployment tab and from the targets select Heroku. You will need your Heroku app name (see above) and your Heroku api key which you can find under your account settings under the Heroku dashboard:

Codeship settings for heroku deployment

We will be deploying from our master branch. Once you are happy with your settings click on the little green tick icon to save the information. Time to test our set up! We just need to make one little change to our app configuration which is handy because that will allow us to commit and a change and verify the whole process from start to finish. In the previous section we have configured our web server to listen on port 3000, well Heroku assigns a part dynamically, so we to account for that by editing our server.js file by adding process.env.PORT to our listen function:

var express = require('express');
var app = express();

app.use(express.static(__dirname + '/app'));

var server = app.listen(process.env.PORT || 3000, function() {
console.log('Listening on port %d', server.address().port);
});

Now let’s commit the change:

git add server.js
git commit -m "Server configured to handle dynamic port allocation"
git push

If we check our build dashboard we should see a succesful build and deployment to our Heroku instance:

Successful build and deployment

The build process checks that we get a 200 response back and marks the build as successful, so let’s open up our browser to see the results of our work:

Weatherly running on Heroku

And there you are your Continuous Delivery pipeline has been created and in less than a minute we go from commit to production!

Recap

In this last section we:

configued our ci envinronment
it runs our feature test
created a Heroku app
configured our CI environment to deploy to that instance
modified our web server to handle dynamic port allocation

Refactoring our build file

Before we move on to generating our assets, we are going to take a small detour and refactor our build file. In the upcoming sections we will be adding more tasks to it and it will be become difficult to get an overview of what is happening in there.

Here’s what our Gruntfile.js currently looks like:

module.exports = function(grunt) {
'use strict';

grunt.initConfig({
	express: {
 			test: {
   			options: {
     				script: './server.js'
   			}
 			}
	},
	cucumberjs: {
 			src: 'tests/e2e/features/',
 			options: {
   			steps: 'tests/e2e/steps/'
 			}
	}
});

grunt.loadNpmTasks('grunt-express-server');
grunt.loadNpmTasks('grunt-selenium-webdriver');
grunt.loadNpmTasks('grunt-cucumber');

grunt.registerTask('e2e', [
	'selenium_start',
	'express:test',
	'cucumberjs',
	'selenium_stop',
	'express:test:stop'
]);
};

And here’s what it will end up looking like once we are done:

module.exports = function(grunt) {
'use strict';

  	grunt.loadTasks('build');		
  	
grunt.registerTask('e2e', [
	'selenium_start',
	'express:test',
	'cucumberjs',
	'selenium_stop',
	'express:test:stop'
]);
};

We kick things off as always with a new branch:

1 git checkout -b refactor-gruntfile

Create a new folder in the root of our project called build, this is where we will put our specfici grunt tasks. Let’s start with the express configuration. In our build folder create a file called express.js and add the following:

(function(module) {
   'use strict';
   var config = {
       test: {
           options: {
               script: './server.js'
           }
       }
   };

   module.exports = function(grunt) {
       grunt.loadNpmTasks('grunt-express-server');

       grunt.config('express', config);
   };
})(module);

We hav basically taken all of the Express configuration out of the Gruntfile.js and moved the loading of the npm task into this file. In order for Grunt to now load this file we can use the grunt.loadTasks('build'); directive.

module.exports = function(grunt) {
'use strict';

grunt.initConfig({
	cucumberjs: {
 			src: 'tests/e2e/features/',
 			options: {
   			steps: 'tests/e2e/steps/'
 			}
	}
});

grunt.loadTasks('build');

grunt.loadNpmTasks('grunt-express-server');
grunt.loadNpmTasks('grunt-selenium-webdriver');
grunt.loadNpmTasks('grunt-cucumber');

grunt.registerTask('e2e', [
	'selenium_start',
	'express:test',
	'cucumberjs',
	'selenium_stop',
	'express:test:stop'
]);
};

Running > grunt e2e again should confirm that all is still well and our end to end test still work. Next let’s move the Cucumber task into build\cucumber.js

(function(module) {
   'use strict';
   var config = {
       src: 'tests/e2e/features/',
       options: {
           steps: 'tests/e2e/steps/'
       }
   };

   module.exports = function(grunt) {
       grunt.loadNpmTasks('grunt-selenium-webdriver');
       grunt.loadNpmTasks('grunt-cucumber');

       grunt.config('cucumberjs', config);
   };
})(module);

Once we have removed the configuration of the task and the loading of these we are in the state described at the outset of this chapter:

module.exports = function(grunt) {
'use strict';

  	grunt.loadTasks('build');		
  	
grunt.registerTask('e2e', [
	'selenium_start',
	'express:test',
	'cucumberjs',
	'selenium_stop',
	'express:test:stop'
]);
};

Let’s validate things once more time: > grunt e2e and you should see the following output:

Running "selenium_start" task
seleniumrc webdriver ready on 127.0.0.1:4444

Running "express:test" (express) task
Starting background Express server
Listening on port 3000

Running "cucumberjs:src" (cucumberjs) task
...

1 scenario (1 passed)
3 steps (3 passed)

Running "selenium_stop" task

Running "express:test:stop" (express) task
Stopping Express server

Done, without errors.

With that done we can commit our changes to our repository:

> git add .
> git commit -m "Refactored our Gruntfile"
> git checkout master
> git merge refactor-gruntfile
> git push

Extending our build file by linting our code

To appreciate how convenient this approach is, let’s add a new task to lint our code:

1 checkout -b jshint-task

I like using JSHint, it’s prescriptive enough without being overbearing. You can install it using:

1 npm install grunt-contrib-jshint --save-dev

You can override the settings by either by specifying a .jshintrc file. This is a good idea particularly if you working as part of a team as you can share the configuration and thus all adhere to the conventions of the project. Let’s create a placeholder file:

1 touch .jshintrc

Here are a few settings that have been useful in previous projects to get the call rolling:

{
   "strict": true,
   "unused": true,
   "undef": true,
   "camelcase": true,
   "curly": true,
   "eqeqeq": true,
   "forin": true,
   "indent": 4,
   "newcap": true,
   "trailing": true,
   "maxdepth": 2,
   "browser": true,
   "devel": true,
   "node": true,
   "quotmark": true,

   "globals": {
       "sinon": false,
       "define": false,
       "beforeEach": false,
       "afterEach": false,
       "expect": false,
       "describe": false,
       "it": false,
       "xdescribe": false,
       "ddescribe": false,
       "xit": false,
       "iit": false,
       "jasmine": false
   }
}

Now for defining the task, create a build/lint.js file with the following content:

(function (module) {
   var config = {
       options: {
           jshintrc: './.jshintrc'
       },
       source: {
           src: [
               './Gruntfile.js',
               './build/**/*.js',
               './tests/**/*.js',
               './js/**/*.js',
           ]
       },
   };
   
   module.exports = function (grunt) {
       grunt.loadNpmTasks('grunt-contrib-jshint');
       
       grunt.config('jshint', config);
   }
})(module);

You can now run this task using > grunt jshint:

Running "jshint:source" (jshint) task
>> 5 files lint free.

Done, without errors.

You can add this task to a watcher, but I find that it slows the feedback loop, instead I add to a pre-commit hook, so that this only runs before I check my code in. We will also add it to our CI process, just in case someone forgets to add it to their pre-commit hook. To add a pre-commit hookl we need to do is create the following file .git/hooks/pre-commit with the following content:

#!/bin/sh
#
# Pre-commit hooks

# Run lint task before committing
grunt jshint

Add exit code.

To test this, let’s commit and merge:

git add .
git commit -m "Added linting"

Running "jshint:source" (jshint) task

build/lint.js
 2 |    var config = {
        ^ Missing "use strict" statement.
15 |    }
         ^ Missing semicolon.
21 |    }
         ^ Missing semicolon.

>> 3 errors in 5 files
Warning: Task "jshint:source" failed. Use --force to continue.

Oh lucky we added linting! Let’s fix the problem:

(function (module) {
   'use strict';
   var config = {
       options: {
           jshintrc: './.jshintrc'
       },
       source: {
           src: [
               './Gruntfile.js',
               './build/**/*.js',
               './node_modules/weatherly/**/*.js',
               './tests/**/*.js',
               './js/**/*.js'
           ]
       }
   };

   module.exports = function (grunt) {
       grunt.loadNpmTasks('grunt-contrib-jshint');

       grunt.config('jshint', config);
   };
})(module);

And now let’s ammend our commit:

git add .
git commit -m "Added linting"
Running "jshint:source" (jshint) task
>> 5 files lint free.

Done, without errors.
[jshint-task 8126006] Fixing linting issues
8 files changed, 30 insertions(+), 30 deletions(-)
rewrite build/lint.js (99%)

Now we can merge our changes in:

git checkout master
git merge jshint-task
git push

Recap

We split our tasks into individual modules and introduced grunt.loadTasks directive to pull these modules into our build file. We then added a new lint task to make sure our code was ship shape.

Building our assets

Now that we have a pipeline up and running it’s time to turn our attention to dealing with building our code and assets and figure out how are our app will consume these. We do not want to check in our generated assets, however Heroku deploys using a git mechanism.

Let’s start by creating some tasks to generate our css, then concatenate and ulgyfy our JS and we’ll finish by deploying these assets to Heroku as part of a successful build. We’ll also add some tasks to run these tasks on our local machine and have these re-generated when we save changes to the file.

1 git checkout -c generate-assets

TODO: why do we generate our assets?

Compile our less to css

Let’s tackle with our CSS files. The first thing we want to do is add the destination folder for our css content to the .gitignore list:

node_modules
.idea
bower_components
phantomjsdriver.log
app/css/

Under our source folder let’s create a less folder and create a main.less file in it. Here’s content of the file:

1 @import '../../bower_components/bootstrap/less/bootstrap';

Our build tasks will take this import directive and create us a nice main.css file that we can then use in our app.

1 npm install grunt-contrib-less --save-dev

And now let’s create a task to generate our css files by adding a less.js file to our build folder:

(function(module) {
   'use strict';
   var config = {
       production: {
           options: {
               paths: ['app/css/'],
               cleancss: true
           },
           files: {
               'app/css/main.css': 'src/less/main.less'
           }
       }
   };

   module.exports = function(grunt) {
       grunt.loadNpmTasks('grunt-contrib-less');

       grunt.config('less', config);
   };
})(module);

To invoke this we could just type grunt less:production, but will doing more building of assets, so let’s wrap this in a custom task in our Gruntfile.js

module.exports = function (grunt) {
   'use strict';

   grunt.loadTasks('build');

   grunt.registerTask('generate', ['less:production']);
   
   grunt.registerTask('e2e', [
       'selenium_start',
       'express:test',
       'cucumberjs',
       'selenium_stop',
       'express:test:stop'
   ]);
};

When you run > grunt generate, you should see the following output:

1 Running "less:production" (less) task
2 File app/css/main.css created: 131.45 kB â†’ 108.43 kB

If you were to start up our server and browse to localhost:3000, our UI should have more of a Bootstrap feel to it!

Rendered HTML with generated css

Now bootstrap also needs some fonts, so let’s move these across as part of the build.

1 npm install grunt-contrib-copy --save-dev

And add a simple task to copy our fonts across as well, create a copy.js in our build folder:

(function(module) {
   'use strict';
   var config = {
       fonts: {
           expand: true,
           src: ['bower_components/bootstrap/fonts/*'],
           dest: 'app/fonts/',
           filter: 'isFile',
           flatten: true
       }
   };

   module.exports = function(grunt) {
       grunt.loadNpmTasks('grunt-contrib-copy');

       grunt.config('copy', config);
   };
})(module);

Let’s add this opying of fonts to our generate task, by editing our Gruntfile.js.

module.exports = function (grunt) {
   'use strict';

   grunt.loadTasks('build');

   grunt.registerTask('generate', ['less:production', 'copy:fonts']);
   
   grunt.registerTask('e2e', [
       'selenium_start',
       'express:test',
       'cucumberjs',
       'selenium_stop',
       'express:test:stop'
   ]);
};

Running >grunt generate task should now also copy our fonts across.

Fonts now included

This is great, but how do we get this to run as part of our successful build?

Heroku build packs

Heroku has a way to run commands after a build, these come in the form of build packs. Luckily for us someone has already gone through the effort of creating one to run Grunt after an install.

I have to say it’s not ideal, however given Heroku’s git based deployment approach, we have little choice but to generate these as part of the deployement. Typicall you would rely on the build to generate a package with all of the generated assets ready for consumption. This works though and does not force us to commit our generated assets into our repository.

So here’s how you go about installing our Build Pack for Grunt (be sure to replace --app lit-meadow-5649 with your actual heroku app name):

heroku login

heroku config:add BUILDPACK_URL=https://github.com/mbuchetics/heroku-buildpack-n\
odejs-grunt.git --app lit-meadow-5649

heroku config:set NODE_ENV=production --app lit-meadow-5649

Then we modify our Gruntfile to include a new heroku:production task, which basically references our build task:

module.exports = function (grunt) {
'use strict';

   grunt.loadTasks('build');

   grunt.registerTask('generate', ['less:production', 'copy:fonts']);
   grunt.registerTask('e2e', [
       'selenium_start',
       'express:test',
       'cucumberjs',
       'selenium_stop',
       'express:test:stop'
   ]);
   
   grunt.registerTask('heroku:production', 'generate');
};

The final step involves re-jigging package.json to include those newly added grunt tasks as a general dependency:

   {
   "name": "weatherly",
   "version": "0.0.0",
   "description": "Building a web app guided by tests",
   "main": "index.js",
   "engines": {
       "node": "~0.10.28"
   },
   "scripts": {
       "test": "grunt test"
   },
   "repository": {
       "type": "git",
       "url": "https://github.com/gregstewart/weatherly.git"
   },
   "author": "Greg Stewart",
   "license": "MIT",
   "bugs": {
       "url": "https://github.com/gregstewart/weatherly/issues"
   },
   "homepage": "https://github.com/gregstewart/weatherly",
   "dependencies": {
       "express": "^4.4.5",
       "grunt-contrib-copy": "^0.5.0",
       "grunt-contrib-less": "^0.11.3"
   },
   "devDependencies": {
       "chai": "^1.9.1",
       "cucumber": "^0.4.0",
       "grunt": "^0.4.5",
       "grunt-contrib-copy": "^0.5.0",
       "grunt-contrib-less": "^0.11.3",
       "grunt-cucumber": "^0.2.3",
       "grunt-express-server": "^0.4.17",
       "grunt-selenium-webdriver": "^0.2.420",
       "webdriverjs": "^1.7.1"
   }
}

This is another thing about this approach that I am not a fan of, having to move what are essentially development dependencies into our production dependencies.

Now we are nearly ready to test this out, however there is one more task we need to add. Since we are using Bower for some of our front end components and we haven’t checked these into our repository, we’ll need to restore them from our bower.json file. Let’s first install a new grunt package to assist us:

1 npm install grunt-bower-task --save

Once again we create a specific bower.js file in our build folder:

(function(module) {
   'use strict';
   var config = {
       install: {
           options: {
               cleanTargetDir: false,
               targetDir: './bower_components'
           }
       }
   };

   module.exports = function(grunt) {
       grunt.loadNpmTasks('grunt-bower-task');

       grunt.config('bower', config);
   };
})(module);

Annd register a task in our Gruntfile.js

module.exports = function (grunt) {
'use strict';
   
   grunt.loadTasks('build');

   grunt.registerTask('generate', ['less:production', 'copy:fonts']);
grunt.registerTask('build', ['bower:install', 'generate']);

   grunt.registerTask('e2e', [
       'selenium_start',
       'express:test',
       'cucumberjs',
       'selenium_stop',
       'express:test:stop'
   ]);

   grunt.registerTask('heroku:production', 'build');
};

With that let’s push these changes and see if we can’t have a more nicely styled page appear on our Heroku app!

git add .
git commit -m "Generate less as part of the build and copy fonts to app folder"
git checkout master
git merge code-build
git push origin master

Concatenate and minify our JavaScript

Having generated our CSS at build time, it’s time to turn our attention to concatenating and minifying our JavaScript.

If you recall in our getting started section we set up our project and used Bower to manage our front end dependencies. For our code we will be Browserify and adopting a CommonJS approach to dealing with modules and dependencies.

TODO: CommonJS vs AMD and why

To get started first create a our source directory for our JavaScript, we’ll store our source under:

1 > mkdir node_modules/weatherly/js

Storing them under node_modules has a great benefit when using browserify, you no longer need require your files using relative paths such as this little beauty:

1 var model = require('../../src/js/model/TodaysWeather');

Typing all this out will get tedius very quickly. Time for a file to test our build process, call it TodaysWeather.js and let’s save it under a sub folder called models:

1 > mkdir node_modules/weatherly/js/models
2 > touch node_modules/weatherly/js/models/TodaysWeather.js

And add the following to that file:

var TodaysWeather = function () {
   console.log('test');
};

module.exports = TodaysWeather;

At this point you may be wondering how we are going to commit the code under node_modules/weatherly/js, given how we have set up our .gitignore file. I will come to that shortly.

With that done let’s install a grunt task for Browserify

1 npm install grunt-browserify --save

The reason we have chosen a grunt task is that we will use this to export our source so that browsers can understand module.exports and use it to concatenate our code.

We’ll skip through a few steps below by creating a browserify.js file and editing our Gruntfile.js to include the task we just installed, define the steps to build our JavaScript and include it into our build task:

(function(module) {
   'use strict';
   var config = {
       code: {
          	dest: 'app/js/main.min.js',
           src: 'node_modules/weatherly/js/**/*.js'            			}
   };
   
   module.exports = function(grunt) {
       grunt.loadNpmTasks('grunt-browserify');

       grunt.config('browserify', config);
   };
})(module);

The Gruntfile.js:

module.exports = function (grunt) {
'use strict';

grunt.loadTasks('build');

grunt.registerTask('generate', ['less:production', 'copy:fonts', 'browserify:co\
de']);
grunt.registerTask('build', ['bower:install', 'generate']);
grunt.registerTask('e2e', [
       'selenium_start',
       'express:test',
       'cucumberjs',
       'selenium_stop',
       'express:test:stop'
   ]);

   grunt.registerTask('heroku:production', 'build');
};

If we now run our generate task you should find a main.min.js file under app/js, which contains a bunch of Browserify and our test file. However you will notice that while it’s concatenated it’s not minified. Let’s fix this.

I chose to go with Uglifyify, as always let’s just install it:

1 npm install uglifyify --save

And then edit our browserify.js file and telling the task to use it is a transform:

(function(module) {
   'use strict';
   var config = {
       code: {
           dest: 'app/js/main.min.js',
           src: 'node_modules/weatherly/js/**/*.js',
           options: {
               transform: ['uglifyify']
           }
       }
   };
   
   module.exports = function(grunt) {
       grunt.loadNpmTasks('grunt-browserify');

       grunt.config('browserify', config);
   };
})(module);

If you now run our generate task, the contents of main should be nicely minified. Now all that’s left to do is edit our index.html file and add our generated JavaScript file:

<!DOCTYPE html>
<!--[if lt IE 7]>      <html class="no-js lt-ie9 lt-ie8 lt-ie7"> <![endif]-->
<!--[if IE 7]>         <html class="no-js lt-ie9 lt-ie8"> <![endif]-->
<!--[if IE 8]>         <html class="no-js lt-ie9"> <![endif]-->
<!--[if gt IE 8]><!--> <html class="no-js"> <!--<![endif]-->
   <head>
       <meta charset="utf-8">
       <meta http-equiv="X-UA-Compatible" content="IE=edge">
       <title>Weatherly - Forecast for London</title>
       <meta name="description" content="">
       <meta name="viewport" content="width=device-width, initial-scale=1">

       <!-- Place favicon.ico and apple-touch-icon.png in the root directory -->

       <link rel="stylesheet" href="css/main.css">
   </head>
   <body>
       <!--[if lt IE 7]>
           <p class="browsehappy">You are using an <strong>outdated</strong> br\
owser. Please <a href="http://browsehappy.com/">upgrade your browser</a> to impr\
ove your experience.</p>
       <![endif]-->

       <!-- Add your site or application content here -->
       <div class="container">
           <div class="header">
               <ul class="nav nav-pills pull-right">
                   <li class="active"><a href="#">Home</a></li>
                   <li><a href="#">About</a></li>
                   <li><a href="#">Contact</a></li>
               </ul>
           </div>

           <div class="jumbotron">
               <h1>London Right Now</h1>
               <p class="temperature">14 degrees</p>
               <p>Mostly cloudy - feels like 14 degrees</p>
           </div>

           <div class="row marketing">
               <div class="col-lg-6">
                   <h4>NEXT HOUR</h4>
                   <p>Mostly cloudy for the hour.</p>

                   <h4>NEXT 24 HOURS</h4>
                   <p>Mostly cloudy until tomorrow afternoon.</p>
               </div>
           </div>

           <div class="footer">
               <p><span class="glyphicon glyphicon-heart"></span> from Weatherl\
y</p>
           </div>

       </div>
       <p></p>

       <script src="//ajax.googleapis.com/ajax/libs/jquery/1.10.2/jquery.min.js\
"></script>
       <script>window.jQuery || document.write('<script src="js/vendor/jquery-1\
.10.2.min.js"><\/script>')</script>

       <!-- Google Analytics: change UA-XXXXX-X to be your site's ID. -->
       <script>
           (function(b,o,i,l,e,r){b.GoogleAnalyticsObject=l;b[l]||(b[l]=
                   function(){(b[l].q=b[l].q||[]).push(arguments)});b[l].l=+new\
Date;
               e=o.createElement(i);r=o.getElementsByTagName(i)[0];
               e.src='//www.google-analytics.com/analytics.js';
               r.parentNode.insertBefore(e,r)}(window,document,'script','ga'));
           ga('create','UA-XXXXX-X');ga('send','pageview');
       </script>
       <script src="js/main.min.js"></script>
   </body>
</html>

Before we commit our changes let’s edit our .gitignore file one more time and tell it not to include our generated JavaScript:

node_modules
.idea
bower_components
phantomjsdriver.log
app/css/
app/fonts/
app/js/

While are here let’s fix our git configuration so that it includes our app code by editing our .gitignore file to look as follows:

.idea
bower_components
phantomjsdriver.log
app/css/
app/fonts/
app/js/
node_modules/*
!node_modules/weatherly

By changing the blanket exclusion rule for our node_modules to one using exceptions, we can now commit the weatherly code that sits under our node_modules folder. That’s what the last two lines do:

1 node_modules/*
2 !node_modules/weatherly

Now when you type git add . it will include all if your changes:

> git status
> # On branch generate-assets
> # Changes to be committed:
> #   (use "git reset HEAD <file>..." to unstage)
> #
> #	modified:   .gitignore
> #	modified:   Gruntfile.js
> #	new file:   node_modules/weatherly/js/model/TodaysWeather.js
> #	modified:   package.json
> #	modified:   app/index.html
> #
> # Changes not staged for commit:
> #   (use "git add/rm <file>..." to update what will be committed)
> #   (use "git checkout -- <file>..." to discard changes in working directory)
> #

Let’s commit, merge and push to our remote repository:

git add .
git commit -m "JavaScript browserified and uglyfied"
git checkout master
git merge generate-assets
git push

TODO recap for the chapter

Unit tests

Up until now we have been very much focused on setting up our build pipeline and writing a high level feature tests. And while I promised that it was time to write some code, we do have do a few more setup steps to carry out before we can get stuck in. To get confidence in our code we will be writing JavaScript modules using tests and we want those tests to run all the time (i.e. with each save). To that end we need to set up some more tasks to run those tests for us and add them to our build process.

Setting up our unit test runner using karma

I have chosen Karma as our Unit test runner, if you are new to Karma I suggest you take a peak at some of the videos on the site. It comes with a variety of plugins and supports basically all of the popular unit test frameworks. As our testing framework we will use Jasmine.

Before going to far, let’s quickly create a few folders in the root of our project. You should already have a node_modules/weatherly/src/js, which is where we will store all of our JavaScript source code. We already have a task to concatenate/minify and move it to our app folder. Now we just need to create a unit folder for our unit tests. So the structure of our code and tests will look as follows:

-> tests
-> unit
-> node_modules
-> weatherly
	->js

As with all tasks, let’s create a new branch:

1 > git checkout -b test-runner

And then let’s install the package and add it to our package.json file:

1 > npm install karma --save-dev

Ok time to create our Karma configuration file, typically you would type in the root of your project:

1 > karma init karma.conf.js

This would guide you through the process of setting up your test runner, here’s how I answered the setup questions:

Which testing framework do you want to use ?
Press tab to list possible options. Enter to move to the next question.
> jasmine

Do you want to use Require.js ?
This will add Require.js plugin.
Press tab to list possible options. Enter to move to the next question.
> no

Do you want to capture any browsers automatically ?
Press tab to list possible options. Enter empty string to move to the next quest\
ion.
> PhantomJS
> 

What is the location of your source and test files ?
You can use glob patterns, eg. "js/*.js" or "test/**/*Spec.js".
Enter empty string to move to the next question.
> node_modules/weatherly/js/**/*.js,
> tests/unit/**/*.js
> 

Should any of the files included by the previous patterns be excluded ?
You can use glob patterns, eg. "**/*.swp".
Enter empty string to move to the next question.
> 

Do you want Karma to watch all the files and run the tests on change ?
Press tab to list possible options.
> no

Config file generated at "/Users/writer/Projects/github/weatherly/karma.conf.js".

And here’s the corresponding configuration that was generated:

// Karma configuration
// Generated on Sun Jul 20 2014 16:18:54 GMT+0100 (BST)

module.exports = function (config) {
   config.set({

       // base path that will be used to resolve all patterns (eg. files, exclu\
de)
       basePath: '',


       // frameworks to use
       // available frameworks: https://npmjs.org/browse/keyword/karma-adapter
       frameworks: ['jasmine'],


       // list of files / patterns to load in the browser
       files: [
           'node_modules/weatherly/js/**/*.js',
           'tests/unit/**/*.js'
       ],


       // list of files to exclude
       exclude: [
       ],


       // preprocess matching files before serving them to the browser
       // available preprocessors: https://npmjs.org/browse/keyword/karma-prepr\
ocessor
       preprocessors: {
       },


       // test results reporter to use
       // possible values: 'dots', 'progress'
       // available reporters: https://npmjs.org/browse/keyword/karma-reporter
       reporters: ['progress'],


       // web server port
       port: 9876,


       // enable / disable colors in the output (reporters and logs)
       colors: true,


       // level of logging
       // possible values: config.LOG_DISABLE || config.LOG_ERROR || config.LOG\
_WARN || config.LOG_INFO || config.LOG_DEBUG
       logLevel: config.LOG_INFO,


       // enable / disable watching file and executing tests whenever any file \
changes
       autoWatch: false,


       // start these browsers
       // available browser launchers: https://npmjs.org/browse/keyword/karma-l\
auncher
       browsers: ['PhantomJS'],


       // Continuous Integration mode
       // if true, Karma captures browsers, runs the tests and exits
       singleRun: false
   });
};

Let’s take it for a spin:

> karma start
> INFO [karma]: Karma v0.12.17 server started at http://localhost:9876/
> INFO [launcher]: Starting browser PhantomJS
> WARN [watcher]: Pattern "/Users/writer/Projects/github/weatherly/tests/unit/**\
/*.js" does not match any file.
> INFO [PhantomJS 1.9.7 (Mac OS X)]: Connected on socket iqriF61DkEH0qp-sXlwR wi\
th id 10962078
> PhantomJS 1.9.7 (Mac OS X): Executed 0 of 0 ERROR (0.003 secs / 0 secs)

So we got an error, but that is because we have no tests. Let’s wrap this into a grunt task:

1 > npm install grunt-karma --save-dev

Create a build\test.js file:

(function (module) {
   'use strict';
   var config = {
       karma: {
       	unit: {
           	configFile: 'karma.conf.js'
       	}
   	}
   };
   
   module.exports = function (grunt) {
       grunt.loadNpmTasks('grunt-karma');
       
       grunt.config('karma', config);
   };
})(module);

Let’s try this out our new grunt task:

> grunt karma:unit

> Running "karma:unit" (karma) task
> INFO [karma]: Karma v0.12.17 server started at http://localhost:9876/
> INFO [launcher]: Starting browser PhantomJS
> WARN [watcher]: Pattern "/Users/gregstewart/Projects/github/weatherly/src/js/*\
*/*.js" does not match any file.
> WARN [watcher]: Pattern "/Users/gregstewart/Projects/github/weatherly/tests/un\
it/**/*.js" does not match any file.
> INFO [PhantomJS 1.9.7 (Mac OS X)]: Connected on socket QO4qLCSO-4DZVO7eaRky wi\
th id 9893379
> PhantomJS 1.9.7 (Mac OS X): Executed 0 of 0 ERROR (0.003 secs / 0 secs)
> Warning: Task "karma:unit" failed. Use --force to continue.

> Aborted due to warnings.

Similar output, with the difference that our process terminated this time because of the warnings about no files macthing our pattern. We’ll fix this issue by writing our very first unit test!

Writing and running our first unit test

In the previous chapter we created a source folder and added a sample module, to confirm our build process for our JavaScript assets worked. Let’s go ahead and create one test file, as well as some of the folder structure for our project:

> mkdir tests/unit/
> mkdir tests/unit/model/
> touch tests/unit/model/TodaysWeather-spec.js

What we want to do know is validate our Karma configuration before we starting our real tests, so let’s add a sample test to our TodaysWeather-spec.js:

'use strict';
/* exported TodaysWeather */
var TodaysWeather = require('weatherly/js/model/TodaysWeather');

describe('Today \'s weather', function () {
it('should return 2', function () {
  		expect(1+1).toBe(2);
   });
});

We could try and run our Karma task again, but this would only result in an error, because we are using the CommonJS module approach and we would see an error stating that module is not defined, because our module under tests uses:

1 module.exports = TodaysWeather;

We need to somehow tell our test runner that we use the CommonJS module type and resolve module and require. Once again we will resort to a npm module: karma-commonjs:

1 > npm install karma-commonjs --save-dev

Next we need to update our karma.conf.js file:

// Karma configuration
// Generated on Sun Jul 20 2014 16:18:54 GMT+0100 (BST)

module.exports = function (config) {
   config.set({

       // base path that will be used to resolve all patterns (eg. files, exclu\
de)
       basePath: '',


       // frameworks to use
       // available frameworks: https://npmjs.org/browse/keyword/karma-adapter
       frameworks: ['jasmine', 'commonjs'],


       // list of files / patterns to load in the browser
       files: [
           'node_modules/weatherly/js/**/*.js',
           'tests/unit/**/*.js'
       ],


       // list of files to exclude
       exclude: [
       ],


       // preprocess matching files before serving them to the browser
       // available preprocessors: https://npmjs.org/browse/keyword/karma-prepr\
ocessor
       preprocessors: {
           'node_modules/weatherly/js/**/*.js': ['commonjs'],
           'tests/unit/**/*.js': ['commonjs']
       },


       // test results reporter to use
       // possible values: 'dots', 'progress'
       // available reporters: https://npmjs.org/browse/keyword/karma-reporter
       reporters: ['progress'],


       // web server port
       port: 9876,


       // enable / disable colors in the output (reporters and logs)
       colors: true,


       // level of logging
       // possible values: config.LOG_DISABLE || config.LOG_ERROR || config.LOG\
_WARN || config.LOG_INFO || config.LOG_DEBUG
       logLevel: config.LOG_INFO,


       // enable / disable watching file and executing tests whenever any file \
changes
       autoWatch: false,


       // start these browsers
       // available browser launchers: https://npmjs.org/browse/keyword/karma-l\
auncher
       browsers: ['PhantomJS'],


       // Continuous Integration mode
       // if true, Karma captures browsers, runs the tests and exits
       singleRun: true
   });
};

We added commonjs to the frameworks block and then configured the preprocessor block to process our source and test files using our chosen module type. Let’s try this again:

> grunt karma:unit
> Running "karma:unit" (karma) task
> INFO [karma]: Karma v0.12.17 server started at http://localhost:9876/
> INFO [launcher]: Starting browser PhantomJS
> INFO [PhantomJS 1.9.7 (Mac OS X)]: Connected on socket 3i335x4S_5GG88E7TsOM wi\
th id 58512369
> PhantomJS 1.9.7 (Mac OS X): Executed 1 of 1 SUCCESS (0.005 secs / 0.002 secs)

> Done, without errors.

Perfect!

Running our tests as part of the build

Now that we have our test runner set up’ let’s add it to our build process. This is going to require us to register a new task as we will need to do a few things:

build our assets
run our unit tests
run our end to end tests

Let’s go ahead and create a task called test in our Gruntfile and configure it to execute these tasks:

module.exports = function (grunt) {
'use strict';
   
   grunt.registerTask('generate', ['less:production', 'copy:fonts', 'browserify\
:code']);
   grunt.registerTask('build', ['bower:install', 'generate']);
   
   grunt.registerTask('e2e', [
       'selenium_start',
       'express:test',
       'cucumberjs',
       'selenium_stop',
       'express:test:stop'
   ]);

   grunt.registerTask('test', ['build', 'karma:unit', 'e2e']);

   grunt.registerTask('heroku:production', 'build');
};

And let’s make sure everything runs as intended:

> grunt test
> Running "less:production" (less) task
> File app/css/main.css created: 131.45 kB → 108.43 kB

> Running "copy:fonts" (copy) task
> Copied 4 files

> Running "browserify:dist" (browserify) task

> Running "karma:unit" (karma) task
> INFO [karma]: Karma v0.12.17 server started at http://localhost:9876/
> INFO [launcher]: Starting browser PhantomJS
> INFO [PhantomJS 1.9.7 (Mac OS X)]: Connected on socket 1kikUD-UC4_Gd6Qh9T49 wi\
th id 53180162
> PhantomJS 1.9.7 (Mac OS X): Executed 1 of 1 SUCCESS (0.002 secs / 0.002 secs)

> Running "selenium_start" task
> seleniumrc webdriver ready on 127.0.0.1:4444

> Running "express:test" (express) task
> Starting background Express server
> Listening on port 3000

> Running "cucumberjs:src" (cucumberjs) task
> ...

> 1 scenario (1 passed)
> 3 steps (3 passed)

> Running "selenium_stop" task

> Running "express:test:stop" (express) task
> Stopping Express server

> Done, without errors.

If you recall we configured our build to execute grunt e2e, we need to update this now to execute grunt test. Log into to your Codeship dashboard and edit the test configuration:

Codeship dashboard with updating test configuration

Ready to give this is a spin?

> git status > git add . > git commit -m “Karma test configuration added and new build test task created” > git checkout master > git merge test-runner > git push

If we keep an eye on our dashboard we should see a build kicked-off and test task being executed:

Codeship dashboard with updating test configuration

Continuously running our tests

So far so good. While it’s it’s nice to have our tests execute manually, let’s automate this. Could it be as simple as setting the karma.conf.js setting singleRun to false and autoWatch to true, well kind of. When running things on our build server we still want the single run to be true, however for local development purposes it should always run. So let’s tackle this:

1 > git checkout -b run-tests-continuously

Let’start by modifying our karma.conf.js file to run tests continuously:

// Karma configuration
// Generated on Sun Jul 20 2014 16:18:54 GMT+0100 (BST)

module.exports = function (config) {
   config.set({

       // base path that will be used to resolve all patterns (eg. files, exclu\
de)
       basePath: '',


       // frameworks to use
       // available frameworks: https://npmjs.org/browse/keyword/karma-adapter
       frameworks: ['jasmine', 'commonjs'],


       // list of files / patterns to load in the browser
       files: [
           'node_modules/weatherly/js/**/*.js',
           'tests/unit/**/*.js'
       ],


       // list of files to exclude
       exclude: [
       ],


       // preprocess matching files before serving them to the browser
       // available preprocessors: https://npmjs.org/browse/keyword/karma-prepr\
ocessor
       preprocessors: {
           'node_modules/weatherly/js/**/*.js': ['commonjs'],
           'tests/unit/**/*.js': ['commonjs']
       },


       // test results reporter to use
       // possible values: 'dots', 'progress'
       // available reporters: https://npmjs.org/browse/keyword/karma-reporter
       reporters: ['progress'],


       // web server port
       port: 9876,


       // enable / disable colors in the output (reporters and logs)
       colors: true,


       // level of logging
       // possible values: config.LOG_DISABLE || config.LOG_ERROR || config.LOG\
_WARN || config.LOG_INFO || config.LOG_DEBUG
       logLevel: config.LOG_INFO,


       // enable / disable watching file and executing tests whenever any file \
changes
       autoWatch: true,


       // start these browsers
       // available browser launchers: https://npmjs.org/browse/keyword/karma-l\
auncher
       browsers: ['PhantomJS'],


       // Continuous Integration mode
       // if true, Karma captures browsers, runs the tests and exits
       singleRun: false
   });
};

Try this out by running grunt karma:unit and after the first run has completed making a change to our source TodaysWeather file:

> grunt karma:unit
> Running "karma:unit" (karma) task
> INFO [karma]: Karma v0.12.17 server started at http://localhost:9876/
> INFO [launcher]: Starting browser PhantomJS
> INFO [PhantomJS 1.9.7 (Mac OS X)]: Connected on socket 9k2m2-j9Ets37p7sWD2Y wi\
th id 21051890
> PhantomJS 1.9.7 (Mac OS X): Executed 1 of 1 SUCCESS (0.007 secs / 0.003 secs)
> INFO [watcher]: Changed file "/Users/gregstewart/Projects/github/weatherly/nod\
e_modules/weatherly/js/model/TodaysWeather.js".
> PhantomJS 1.9.7 (Mac OS X): Executed 1 of 1 SUCCESS (0.005 secs / 0.002 secs)

Exactly what we wanted. Let’s now tackle our build versus development problem. We will just create a seperate build task in our test.js file that uses the same configuration file but overrides the properties we need for our build environment:

(function (module) {
   'use strict';
   var config = {
       dev: {
           configFile: 'karma.conf.js'
       },
       ci: {
           configFile: 'karma.conf.js',
           singleRun: true,
           autoWatch: false
       }
   };

   module.exports = function (grunt) {
       grunt.loadNpmTasks('grunt-karma');

       grunt.config('karma', config);
   };
})(module);

I took the chance to rename the karma:unit task to karma:dev and create a karma:ci task. The next thing was update the test task in our Gruntfile.js to also execute karma:ci instead of karma:unit.

module.exports = function (grunt) {
   'use strict';

   grunt.loadTasks('build');

   grunt.registerTask('generate', ['less:production', 'copy:fonts', 'browserify\
:code']);
   grunt.registerTask('build', ['bower:install', 'generate']);

   grunt.registerTask('e2e', [
       'selenium_start',
       'express:test',
       'cucumberjs',
       'selenium_stop',
       'express:test:stop'
   ]);

   grunt.registerTask('test', ['build', 'karma:ci', 'e2e']);
   grunt.registerTask('heroku:production', 'build');
};

Let’s test all those changes:

> grunt test       
> Running "bower:install" (bower) task
> >> Installed bower packages
> >> Copied packages to /Users/gregstewart/Projects/github/weatherly/bower_compo\
nents

> Running "less:production" (less) task
> File app/css/main.css created: 131.45 kB → 108.43 kB

> Running "copy:fonts" (copy) task
> Copied 4 files

> Running "browserify:code" (browserify) task

> Running "karma:ci" (karma) task
> INFO [karma]: Karma v0.12.17 server started at http://localhost:9876/
> INFO [launcher]: Starting browser PhantomJS
> INFO [PhantomJS 1.9.7 (Mac OS X)]: Connected on socket 67MYRP0HFPzhHE9wY3vt wi\
th id 58848767
> PhantomJS 1.9.7 (Mac OS X): Executed 1 of 1 SUCCESS (0.002 secs / 0.002 secs)

> Running "selenium_start" task
> seleniumrc webdriver ready on 127.0.0.1:4444

> Running "express:test" (express) task
> Starting background Express server
> Listening on port 3000

> Running "cucumberjs:src" (cucumberjs) task
> ...

> 1 scenario (1 passed)
> 3 steps (3 passed)

> Running "selenium_stop" task

> Running "express:test:stop" (express) task
> Stopping Express server

> Done, without errors.

Time to commit our changes back to master and push to origin and see the whole thing go through our build pipeline:

> git add .
> git commit -m "Run tests continuously in dev and single run on CI"
> git checkout master
> git merge run-tests-continuously
> git push

Now check your CI server and you should see the following if it all went to plan:

Codeship dashboard with updated ci test configuration

Adding code coverage

A little bonus while we are setting up test infrastructure, code coverage. Now code coverage is one of these topics that sparks almost fanatical discussions, however I find a useful tool to make sure I have covered all of the important parts of my code. Lucky for us, it’s easy to add support to Karma all we need is a plugin:

1 > git checkout -b code-coverage
2 > npm install karma-coverage --save-dev

And modify our karma.conf.js file:

// Karma configuration
// Generated on Sun Jul 20 2014 16:18:54 GMT+0100 (BST)

module.exports = function (config) {
   config.set({

       // base path that will be used to resolve all patterns (eg. files, exclu\
de)
       basePath: '',


       // frameworks to use
       // available frameworks: https://npmjs.org/browse/keyword/karma-adapter
       frameworks: ['jasmine', 'commonjs'],


       // list of files / patterns to load in the browser
       files: [
           'node_modules/weatherly/js/**/*.js',
           'tests/unit/**/*.js'
       ],


       // list of files to exclude
       exclude: [
       ],


       // preprocess matching files before serving them to the browser
       // available preprocessors: https://npmjs.org/browse/keyword/karma-prepr\
ocessor
       preprocessors: {
           'node_modules/weatherly/js/**/*.js': ['commonjs', 'coverage'],
           'tests/unit/**/*.js': ['commonjs'],
       },


       // test results reporter to use
       // possible values: 'dots', 'progress'
       // available reporters: https://npmjs.org/browse/keyword/karma-reporter
       reporters: ['progress', 'coverage'],

       coverageReporter: {
           reporters: [
               { type: 'html'},
               { type: 'text-summary' }
           ],
           dir: 'reports/coverage'
       },

       // web server port
       port: 9876,


       // enable / disable colors in the output (reporters and logs)
       colors: true,


       // level of logging
       // possible values: config.LOG_DISABLE || config.LOG_ERROR || config.LOG\
_WARN || config.LOG_INFO || config.LOG_DEBUG
       logLevel: config.LOG_INFO,


       // enable / disable watching file and executing tests whenever any file \
changes
       autoWatch: true,


       // start these browsers
       // available browser launchers: https://npmjs.org/browse/keyword/karma-l\
auncher
       browsers: ['PhantomJS'],


       // Continuous Integration mode
       // if true, Karma captures browsers, runs the tests and exits
       singleRun: false
   });
};

Running our grunt karma:dev task yields the following output:

> Running "karma:dev" (karma) task
> INFO [karma]: Karma v0.12.17 server started at http://localhost:9876/
> INFO [launcher]: Starting browser PhantomJS
> INFO [PhantomJS 1.9.7 (Mac OS X)]: Connected on socket OVbmSp9OmFMK23l5jA2J wi\
th id 80988698
> PhantomJS 1.9.7 (Mac OS X): Executed 1 of 1 SUCCESS (0.005 secs / 0.002 secs)

> =============================== Coverage summary =============================\
==
> Statements   : 83.33% ( 5/6 )
> Branches     : 100% ( 2/2 )
> Functions    : 50% ( 1/2 )
> Lines        : 66.67% ( 2/3 )
> ==============================================================================\
==
> ^C
> Done, without errors.

There’s more information in the shape of an HTML report to be found under reports/coverage/. Here’s a what that looks like

Istanbule code coverage report

One final thing before we close off this section. You may not want to run your coverage report as part the CI process. If you do then ignore this part. By editing our test.js and for our karma:ci task overriding the reporter step with reporters: ['progress'] we can skip this step for our build.

(function (module) {
   'use strict';
   var config = {
       dev: {
           configFile: 'karma.conf.js'
       },
       ci: {
           configFile: 'karma.conf.js',
           singleRun: true,
           autoWatch: false,
           reporters: ['progress']
       }
   };

   module.exports = function (grunt) {
       grunt.loadNpmTasks('grunt-karma');

       grunt.config('karma', config);
   };
})(module);

We also do not want to commit our reports to our repos, so another .gitignore tweak is needed:

.idea
bower_components
reports
phantomjsdriver.log
app/css
app/fonts
app/js
node_modules/*
!node_modules/weatherly

Time to commit and merge our changes:

> git add .	
> git commit -m "added coverage to dev process"
> git checkout master
> git merge code-coverage 
> git push

Linting as part of the build

Since we are about to write some code we should circle back to adding the lint task to ci process. This is really straight forward now:

1  git checkout -b linting-the-build

Open up Gruntfile.js and add the jshint task to our test task.

module.exports = function (grunt) {
   'use strict';

   grunt.loadTasks('build');

   grunt.registerTask('generate', ['less:production', 'copy:fonts', 'browserify\
:code']);
   grunt.registerTask('build', ['bower:install', 'generate']);

   grunt.registerTask('e2e', [
       'selenium_start',
       'express:test',
       'cucumberjs',
       'selenium_stop',
       'express:test:stop'
   ]);

   grunt.registerTask('test', ['jshint', 'build', 'karma:ci', 'e2e']);
   grunt.registerTask('heroku:production', 'build');
};	

To verify it works locally just type > grunt test

Running "jshint:source" (jshint) task
>> 5 files lint free.

Running "bower:install" (bower) task
>> Installed bower packages
>> Copied packages to /Users/gregstewart/Projects/github/weatherly/bower_compone\
nts

Running "less:production" (less) task
File app/css/main.css created: 131.45 kB → 108.43 kB

Running "copy:fonts" (copy) task
Copied 4 files

Running "browserify:code" (browserify) task

Running "karma:ci" (karma) task
INFO [karma]: Karma v0.12.17 server started at http://localhost:9876/
INFO [launcher]: Starting browser PhantomJS
INFO [PhantomJS 1.9.7 (Mac OS X)]: Connected on socket lR_IEn9s3FvaphN90JfV with\
id 32288954
PhantomJS 1.9.7 (Mac OS X): Executed 1 of 1 SUCCESS (0.002 secs / 0.002 secs)

Running "selenium_start" task
seleniumrc webdriver ready on 127.0.0.1:4444

Running "express:test" (express) task
Starting background Express server
Listening on port 3000

Running "cucumberjs:src" (cucumberjs) task
...

1 scenario (1 passed)
3 steps (3 passed)

Running "selenium_stop" task

Running "express:test:stop" (express) task
Stopping Express server

Done, without errors.

Looking good let’s commit the change and watch it go through the build:

git add .
git commit -m "Added lint to ci/test task"
git checkout master
git pull origin master
git merge linting-the-build
git push origin  master

Recap

We covered quite a bit of ground here:

we set up Karma
wrote a very basic unit test to validate the test runner was working
configured the tests for local continuous testing and single run during the build
added code coverage to our tooling
added linting to our ci run as well

With that onwards to development guided by tests!

Table of Contents

Introduction

Conventions

What we will be building

How we will build it

What you will need

Services you wil need to sign up for

Code editor

Version control: Git

Node.js and NPM

Bower

Grunt

Getting started

Setting up our project

Recap

Writing our first functional test

Web server: Express

Cucumber, WebDriver and Selenium

Selenium

Using Grunt to start and stop the express server

WebDriver

Cucumber

Our first test

Recap

Continuous delivery

Setting up our Continuous Integration environment using Codeship

Setting up Continous Deployment to Heroku

Recap

Refactoring our build file

Extending our build file by linting our code

Recap

Building our assets

Compile our less to css

Heroku build packs

Concatenate and minify our JavaScript

Unit tests

Setting up our unit test runner using karma

Writing and running our first unit test

Running our tests as part of the build

Continuously running our tests

Adding code coverage

Linting as part of the build

Recap