ES6 & TDD: Can I test it?

(Yes you can!)

I like the style of Test Driven Development (TDD), dead or not. I have been using TDD mainly for server side code with C# and NUnit. I think the benefits of writing unit tests for client side code is obvious. Now, with ECMAScript 6 (ES6), we have cool stuff like modules, promises, iterators ... is ES6 testable?

Interested in test driven JavaScript in general? Check out From the Streets of Test Driven Development: JavaScript.

Write, transpile, test?
To use all those cool new JavaScript features today, the source code need to be transpiled to a version that browsers support. What about the unit tests (that is also written in JavaScript)?

The unit tests can (of course) be written in old school JavaScript (ES5). But I think the context switch between the two (ES5/ES6) probably would break the flow. I would like to write both the unit test and the code in ES6. How about using Babel to transpile them both?

Check out my earlier post about some tools I use (like Babel): Sublime ES6 coding - the tools and the flow

QUnit and ES6 arrow functions
I like the simplicity and the basic TDD style of QUnit. I like the words test and assert. Jasmine and Mocha are cool to, using the behavior driven style of writing, but I prefer the classic TDD approach. Maybe it's a mindset thing? 

QUnit uses a test runner, that is where the unit tests are started. The test runner is an html file and lives in a browser (or in PhantomJS). That's the old school world. Transpiled versions of unit tests and transpiled production code will run there. There are some things to think about. QUnit doesn't identify itself as a loadable module (yet). Instead, a variable is added to the global object. By default, QUnit will run when the DOM is loaded. When used with AMD, QUnit have to be paused until the unit test modules are loaded. In this example, I have transpiled ES6 code to AMD modules (RequireJS) using Babel. The test runner is loading a single file that will import all my unit tests.

You will find unit tests, code, settings, project structure and setup on GitHub: 
ES6 and TDD

Example - the script section of the test runner html file, written in old school JavaScript:
(function () {
  'use strict';

  QUnit.config.autostart = false;
 
  require(['script/transpiled/start.js'], function () {
    QUnit.load();
    QUnit.start();
  });
}());


The contents of start.js, importing all unit test modules, written in ES6:
import {} from './modules/exampletest.js';


The unit test, written in ES6:
import foo from 'modules/foo';

QUnit.module('my example tests');

QUnit.test('will this work?', assert => {
     const expected = 'hello foo';

     assert.equal(foo.message, expected);
});

The code under test, written in ES6:
let foo = {
     message: 'hello foo'
};

export default foo; 

The require and imports of the test runner and start.js uses relative urls. That is because I use the same base url as the production code. This enables the simple kind of imports done in the unit test. The code there is written in the same way it would in the production code.

Run with Gulp 
I use Gulp to automate a lot of things: transpiling with Babel, checking for syntax errors with JSHint and running QUnit tests with PhantomJS (i.e. no browser required). All of these will execute as soon as any ES6 file is changed in my project. By doing that, I will get instant feedback without having to interupt the flow.

Give the code a try and let me know what you think about it. What aspects am I missing? What can be improved, changed, refactored?

You will find unit tests, code, settings, project structure and setup on GitHub: 
ES6 and TDD

Sublime ES6 coding - the tools and the flow

Sublime Text 3 and JavaScript - a nice combination
A while ago, I decided to give Sublime Text a try when learning ECMAScript 6. I mostly use Visual Studio, and with Sublime It feels like I'm on a diet! As a side effect I am also learning a little bit of Node, because many packages are based on tools installed with the Node package manager (npm). 

ECMAScript 6 (ES6)
In order to get full ES6 syntax, I have installed the babel-sublime package. Enable the package by open or create a file with a .js extension, select View -> Syntax -> Open all with current extension as ... -> Babel -> JavaScript (Babel).

JSHint
I think JSHint does the job well also with checking for errors in ES6 code. I have only found one issue - grouping exports in a module - but I can live with writing separate multiple exports until it is fixed. I think ESLint also looks very promising, but for now I will keep using JSHint.

SublimeLinter-jshint

Linting ES6?
Selecting Babel as the default syntax for .js files will actually disable the JavaScript linting. The SublimeLinter settings file need syntax mappings for Babel (the selected row in the image below). Add the row and the linting will be enabled again.  

Share the Rules
Instead of adding comments to every single .js file (like the esnext option), I use settings files (named .jshintrc). Are you on a Windows machine and can't create file names starting with a dot? Save the file with the name jshintrc, and rename it from the command prompt using the "ren" command:  
ren jshintrc .jshintrc

Transpile to old school JavaScript with Babel
Using Babel from the command line is really simple and it runs fast. This command will create JavaScript RequireJS style modules (AMD):
babel my/es6/path --modules amd --out-dir destination/path

But running a command after each code change is an interruption, a manual step that should be automated. I use Gulp to run Babel commands and watcher to track changes in files.

Keep the flow with Gulp
With Gulp running in the background, each file change will trigger lint rules validation, ES6-to-ES5 transpilation and unit tests. An example:

var gulp = require('gulp');
var newer = require('gulp-newer');
var babel = require('gulp-babel');
var qunit = require('node-qunit-phantomjs');
var jshint = require('gulp-jshint'); 

gulp.task('lint', function () {
    return gulp.src(source)
        .pipe(jshint())
        .pipe(jshint.reporter('default')) // linting passed
        .pipe(jshint.reporter('fail')); // linting failed
});

gulp.task('transpile', function () {
    return gulp.src(source)
        .pipe(newer(destination)) // is the file changed?
        .pipe(babel({modules: 'amd'})) // run babel and pass options
        .pipe(gulp.dest(destination));
});

gulp.task('qunit', function () {
    qunit('path/to/qunit/testrunner.html', { 'verbose': false });
});

Test Driven ES6 Development with QUnit
This is a separate blog post. Stay tuned!  
Update: Here it is the post: ES6 & TDD - can I test it?