Jasmine is another popular JavaScript unit testing framework. Here I will show how you can get the same automated feedback from your Jasmine . . . → Read More: Run all your JavaScript Jasmine tests on every commit]]> I’ve previously described how to run your QUnit tests and produce a coverage report on every commit. This works great if you happen to have chosen QUnit as your unit testing framework.

Jasmine is another popular JavaScript unit testing framework. Here I will show how you can get the same automated feedback from your Jasmine tests using Grunt. Refer to the full sample project on GitHub: github.com/larsthorup/jsdevenv-jasmine.

Assume that we have the following very simple Jasmine test in src/js/addition.test.js:

/*global describe it expect */
describe('addition', function () {
    'use strict';
 
    it('should return 4 when adding 2 and 2', function () {
        expect(2 + 2).toBe(4);
    });
});

To run this test from the command-line, we need to install the Jasmine-plugin for Grunt. Add this line to package.json:

        "grunt-contrib-jasmine": "0.4.1",

And install it with npm install. You can then configure the plugin in Gruntfile.js:

    grunt.loadNpmTasks('grunt-contrib-jasmine');
    gruntConfig.jasmine = {
        src: {
            src: [
                'src/js/**/*.js',
                '!src/js/**/*.test.js'
            ],
            options: {
                specs: 'src/js/**/*.test.js',
                junit: {
                    path: 'output/testresults'
                }
            }
        }
    };
    grunt.registerTask('test', 'jasmine:src');

You can now run your Jasmine tests from the command line with grunt test. If you try to make the test fail, it will produce output like this:

>grunt test
Running "jasmine:src" (jasmine) task
Testing jasmine specs via phantom
x.........
addition:: should return 4 when adding 2 and 2: failed
  Expected 4 to be 5. (1)
10 specs in 0.003s.
>> 1 failures

Notice that the Jasmine plugin supports JUnit-formatted test results out of the box, so you can configure your CI-server to display test results and trend lines from the files that Jasmine produces in output/testresults.

To produce a coverage report we can use the JavaScript code coverage tool Istanbul that has a plugin for the Jasmine-plugin for Grunt. To install it add this line to package.json:

        "grunt-template-jasmine-istanbul": "0.2.0"

and run npm install. You can then configure the plugin in Gruntfile.js:

    gruntConfig.jasmine.istanbul= {
        src: gruntConfig.jasmine.src.src,
        options: {
            specs: gruntConfig.jasmine.src.options.specs,
            template: require('grunt-template-jasmine-istanbul'),
            templateOptions: {
                coverage: 'output/coverage/coverage.json',
                report: [
                    {type: 'html', options: {dir: 'output/coverage'}},
                    {type: 'cobertura', options: {dir: 'output/coverage/cobertura'}},
                    {type: 'text-summary'}
                ]
            }
        }
    };
    grunt.registerTask('coverage', 'jasmine:istanbul');

You can now run your Jasmine tests with coverage analysis with the command grunt coverage. It will produce output like this:

>grunt coverage
Running "jasmine:istanbul" (jasmine) task
Testing jasmine specs via phantom
..........
=============================== Coverage summary ===============================
Statements   : 100% ( 33/33 )
Branches     : 89.29% ( 25/28 )
Functions    : 100% ( 4/4 )
Lines        : 100% ( 30/30 )
================================================================================

10 specs in 0.062s.
>> 0 failures

Done, without errors.

Istanbul will also product html-output that can be browsed from output/coverage/index.html, and will look like this:

Some CI-servers, like Jenkins, can display coverage information and trend-lines, if the coverage information is in Cobertura-format. We also configured Istanbul to output in Cobertura-format so we can point our CI-server at the files in output/coverage/cobertura.

This post is part of a series on Continuous Integration for front-end JavaScript, read the other posts in the series:

• Automated build for your front-end JavaScript code
• Continuous Integration of your front-end JavaScript code using Travis-CI
• Run all your JavaScript QUnit tests on every commit
• Check your JavaScript code on every save
• No line of your JavaScript code uncovered
• Run all your JavaScript Jasmine tests on every commit

There is a plugin for Grunt that can use the JSCoverage tool to produce a coverage report while . . . → Read More: No line of your JavaScript code uncovered]]> Being able to get fast feedback from failing unit tests is useful. And if you could easily identify the parts of your code that you still need to write tests for, you would get more comprehensive feedback.

There is a plugin for Grunt that can use the JSCoverage tool to produce a coverage report while running your unit tests.

First step is to install JSCoverage. Unfortunately I have not been able to find a working npm package for JSCoverage, so what you can do is download a binary and put it somewhere in your path. The grunt-qunit-cov plugin also needs PhantomJS to be on the path, so you might need to install PhantomJS separately for that.

Grunt has a grunt-qunit-cov plugin that will combine the QUnit runner with JSCoverage.

You will need to configure the plugin, so change your Gruntfile.js to include:

    grunt.loadNpmTasks('grunt-qunit-cov');
    gruntConfig['qunit-cov'] = {
        test:
        {
            minimum: 0.99,
            baseDir: 'src',
            srcDir: 'src/js',
            depDirs: ['src/lib', 'src/test'],
            outDir: 'output/coverage',
            testFiles: ['src/test/index.html']
        }
    };
    grunt.registerTask('coverage', 'qunit-cov');

In this example the plugin will fail the build if the coverage is not 99% or more.

To demonstrate the capabilities of JSCoverage, create an application file src/js/password.js:

/*global window*/
window.passwordStrength = function (password) {
    'use strict';
    var result = 0;
    if (password.length > 4) {
        result += 1;
    }
    if (password.length > 8) {
        result += 1;
    }
    return result;
};

Then add a test for it in src/test/index.html:

<!DOCTYPE html>
<html>
<head>
    <title>jsdevenv tests</title>
    <link rel="stylesheet" href="lib/qunit.css">
</head>
<body>
    <script src="../js/password.js"></script>
    <script async src="lib/qunit.js" onload="runTests()"></script>
    <div id="qunit"></div>
    <script>
        runTests = function() {
            module('password');
            test('strength is 0', function () {
                 equal(passwordStrength('abc'), 0, 'abc');
            });
        }
    </script>
</body>
</html>

Then invoke

  grunt coverage

This will fail with the following output:

  Coverage in 75%
   Error: Coverage don't reach 99%

A detailed report is saved in output/coverage/out/coverage.html

And if you click on the link to password.js, you will see exactly which lines of password.js is not covered by any of the tests.

To fix the broken build, add the following two tests in src/test/index.html:

   test('strength is 1', function () {
     equal(passwordStrength('lemon'), 1, 'abc');
   });
   test('strength is 2', function () {
     equal(passwordStrength('lemonades'), 2, 'abc');
   });

Now grunt coverage will succeed with this message:

  Coverage in 100%

And the coverage reports looks like this:


Most continuous integration systems (like Jenkins, TeamCity and Bamboo, but not yet Travis-CI) allow you to configure a set of artifacts that are made accessible for every build. See this screenshot from TeamCity:

Now you can make sure that you maintain a comprehensive test suite for your front-end JavaScript code. Enjoy!

This post is part of a series on Continuous Integration for front-end JavaScript, read the other posts in the series:

• Automated build for your front-end JavaScript code
• Continuous Integration of your front-end JavaScript code using Travis-CI
• Run all your JavaScript QUnit tests on every commit
• Check your JavaScript code on every save
• No line of your JavaScript code uncovered
• Run all your JavaScript Jasmine tests on every commit

Grunt includes a watch facility that will run a task every time some file is changed. You only need . . . → Read More: Check your JavaScript code on every save]]> Being able to check the quality of your code and run all unit tests in your project on every commit is useful. If you could do it on every save you would get even faster feedback.

Grunt includes a watch facility that will run a task every time some file is changed. You only need to tell Grunt which files to watch and what tasks to run, so change your Gruntfile.js to include:

    grunt.loadNpmTasks('grunt-contrib-watch');
    gruntConfig.watch = {
        scripts: {
            files: ['src/**/*.*'],
            tasks: ['lint', 'test']
        }
    };

You can now open a new terminal window and run

  grunt watch

Then use your editor and edit index.html to intentionally break the test. Save the file, and watch the immediate feedback in the adjacent terminal window. Fix the test, save the file, and see that everything is back in order. You can’t get feedback much faster than that. Enjoy!

This post is part of a series on Continuous Integration for front-end JavaScript, read the other posts in the series:

• Automated build for your front-end JavaScript code
• Continuous Integration of your front-end JavaScript code using Travis-CI
• Run all your JavaScript QUnit tests on every commit
• Check your JavaScript code on every save
• No line of your JavaScript code uncovered
• Run all your JavaScript Jasmine tests on every commit

A lot of projects use continuous integration these days. It is still far more common for back-end projects using C#, Java or . . . → Read More: Automated build for your front-end JavaScript code]]> Update as of April 7, 2013: This blog series has now been extended with Jasmine and Istanbul.
Update as of March 28, 2013: This blog series has now been upgraded to use Grunt-0.4.

A lot of projects use continuous integration these days. It is still far more common for back-end projects using C#, Java or Ruby than it is for JavaScript projects. But front-end projects using JavaScript can also benefit from continuous integration, and this series of blog posts will show you how easy it is to set up using available open source tools.

I will show how to do fully automated code quality analysis with JSHint, unit testing with QUnit, code coverage with JSCoverage and continuous integration with Travis-CI.

Continuous integration means that your code will be checked automatically on every commit. If you commit often, you will get very precise information about what change introduced an error. Frequent and precise feedback is the cheapest way to keep bugs at bay.

All continuous integration systems rely on the ability to do the checking of the code from the command line. This blog post is about front-end JavaScript. While it is meant to be run in a browser, nonetheless there are great tools available for checking this front-end JavaScript code from the command line. Here I will focus on Node and Grunt. You can access the sample code in these blog posts at GitHub.

You will need only a single tool being installed globally on your system, namely Node. All other tools will be added locally to your project directory.

First step is to install Node on your system. Follow the instructions.

Your first goal will be to check your JavaScript code quality using JSHint, a tool that detects errors and potential problems in JavaScript code and enforces coding conventions. To be able to check the code from the command line we will use Grunt, a command line build tool for JavaScript. Grunt has built-in support for JSHint.

You can use the Node Package Manager, npm, to install any other tools you will be using. Npm is configured using a file called package.json located in the root directory of your project. To let Node know that you want to use Grunt, you will need to add Grunt as a development dependency to package.json. I have included some standard Grunt plugins, that we will need later on:

{
  "name": "jsdevenv",
  "version": "0.1.1-1",
  "description": "A sample build environment for JavaScript",
  "author": "Lars Thorup <lars@zealake.com>",
  "devDependencies": {
    "grunt-cli": "0.1.6",
    "grunt": "0.4.0",
    "grunt-contrib-jshint": "~0.1.1",
    "grunt-contrib-qunit": "~0.1.1",
    "grunt-qunit-junit": "~0.1.0",
    "grunt-contrib-watch": "~0.2.0",
    "grunt-qunit-cov": "~0.3.2"
  }
}

You can then install Grunt locally by running the following command in the root directory of your project (the directory with package.json):

  npm install

Next thing to do is to configure Grunt to check your code quality. Grunt needs a configuration file, and we will use Gruntfile.js. A basic Gruntfile.js that will check your code quality looks like this:

/*global module*/
module.exports = function (grunt) {
  'use strict';
 
  var gruntConfig = {};
  grunt.loadNpmTasks('grunt-contrib-jshint');
  gruntConfig.jshint = {
      options: { bitwise: true, camelcase: true, curly: true, eqeqeq: true, forin: true, immed: true,
          indent: 4, latedef: true, newcap: true, noarg: true, noempty: true, nonew: true, plusplus: true,
          quotmark: true, regexp: true, undef: true, unused: true, strict: true, trailing: true,
          maxparams: 3, maxdepth: 2, maxstatements: 50},
      all: [
          'Gruntfile.js',
          'src/js/**/*.js'
      ]
  };
  grunt.initConfig(gruntConfig);
 
};

Based on your style preferences you might want to configure JSHint differently than the example used here.

Note that Gruntfile.js is a JavaScript file, so it makes sense to include this file in the list of files to be checked. You may also need to tweak the second path of the array gruntConfig.jshint.all if your JavaScript files are located somewhere else in the project.

Now you can check the quality of your JavaScript code from the command line by running:

  grunt jshint

Next step would be to configure your continuous integration server to execute the following two steps on every commit to your project:

  npm install
  grunt lint

How to do this will depend on what continuous integration software you are using. In the next blog post I will show how to continuously integrate your JavaScript code with Travis-CI.

This post is part of a series on Continuous Integration for front-end JavaScript, read the other posts in the series:

• Automated build for your front-end JavaScript code
• Continuous Integration of your front-end JavaScript code using Travis-CI
• Run all your JavaScript QUnit tests on every commit
• Check your JavaScript code on every save
• No line of your JavaScript code uncovered
• Run all your JavaScript Jasmine tests on every commit

One of our developers wants to write her BDD features using SpecFlow instead of our existing Cucumber JVM approach. Isn’t it a bad idea having two separate approaches? What are your thoughts on this.

I think it is important that you constantly ask youself how you . . . → Read More: Tool Improvement Spikes]]> A client of mine asked me this question today:

One of our developers wants to write her BDD features using SpecFlow instead of our existing Cucumber JVM approach. Isn’t it a bad idea having two separate approaches? What are your thoughts on this.

I think it is important that you constantly ask youself how you can improve on existing practices. Conducting experiments with a new tool that seems to have benefits over an existing tool is a great way to spike a potential improvement. You are not going to keep the same tool chain over the next 10 years anyway, so better do spikes early than wait until you are forced to change by outside forces.

I am not sure what the benefits might be in this particular case, but from a quick look, it seems like SpecFlow might be better integrated with the rest of the tool chain (.NET, Visual Studio). However, there might be drawbacks as well, such as integration with Jenkins reporting.

I don’t think you should accept that one of the developers (let’s call her Sandra) uses another tool just because she wants to. I also don’t think you should encourage having two separate approaches to solving the same problem.  But you can leverage Sandra’s desire to improve by asking her to run a few experiements to demonstrate answers to some actual questions you can pose in advance, like

• how well does it integrate with Visual Studio in day-to-day work?
• how easy is it to integrate with the existing build scripts and Jenkins reporting?
• how easy is it to write and debug compared to Cucumber?

Then Sandra can do a demo for the team and you can all discuss pros and cons on the basis of her results.

If the team agrees that Cucumber is best, Sandra should throw out her SpecFlow experiments and use Cucumber like the rest of  the team. But when the majority of the team agrees that some new tool seems to be better than the existing one, you can gradually discourage the use of the old tool and educate and encourage the use of the new one.

But . . . → Read More: Automated Performance Testing]]> If you are like most test driven developers, you write automated tests for your software to get fast feedback about potential problems. Most of the tests you write will verify the functional behaviour of the software: When we call this function or press this button, the expected result is that value or that message.

But what about the non-functional behaviour, such as performance: When we perform this query the expected speed of getting results should be no more than that many milliseconds. It is important to be able to write automated performance tests as well, because they can give us early feedback about potential performance problems. But expected performance is not as clear-cut as expected results. Expected results are either correct or wrong. Expected performance is more like a threshold: If the performance is worse than this, we want the test to fail.

At yesterdays meetup I gave the following presentation.

In this introduction we give a high level description of what it is and why it is useful for developers. Then we go into some details on stubs and mocks, test data, UI testing, SQL testing, JavaScript testing, web . . . → Read More: Test and Behavior Driven Development (TDD/BDD)]]> This week I gave a presentation for a client, starting on Test and Behavior Driven Development.

In this introduction we give a high level description of what it is and why it is useful for developers. Then we go into some details on stubs and mocks, test data, UI testing, SQL testing, JavaScript testing, web services testing and how to start doing TDD/BDD on an existing code base.