Test friendly JavaScript modules - without Dependency Injection

A while ago, I was trying to figure out how to use test driven development with ES2015 (also known as ES6 at the time). It turned out to be a nice experience, and I wrote a blog post about it: Can I test it?

However, I had some concerns about the import feature and how to deal with module dependencies. I wrote a blog post about that too: Is the ES6 import feature an anti pattern?

Recently, I have been learning Python and was surprised by the similarities with JavaScript - in coding style, philosophy and language features. I guess Python has been a source of inspiration for the new ES2015 stuff. I have quickly become a fan of Python and I think it is a very nice language.

 At first, as a Python newbie, I stumbled upon the same questions on how to unit test modules containing a bunch of import statements. Luckily, at work I am surrounded with great programmers in general, that also are experts in the Python language. With Python, the answer to my questions was both simple and obvious. Python is a dynamic language: load the dependency in the unit test, then just override it. The code under test will use the already loaded in memory module. Simple, huh? It seems to me that there is no need for c#/java like dependency injections. I guess it was my typed language mindset that had guided me to IoC and DI patterns.

What about JavaScript?
I think it is (almost) as simple! Modules and imports in JavaScript are similar to (but not exactly like) the Python way. In JavaScript, I guess it also depends on the module loader used in the current environment. I have experimented with this. My setup contain ES2015 modules and unit tests, that are transpiled with Babel to RequireJS modules, runs in a browser or with PhantomJS. With this setup, I have managed to override module dependencies with fakes from a unit test. The module under test will actually run the fake dependency, and there is no need for custom Dependency Injection.

An example: a unit test
import foo from 'modules/foo';
import bar from 'modules/bar';

const fakeMessage = 'a fake message.';

const original = bar.getMessage;
const fake = () => fakeMessage;

QUnit.module('my example tests', {
    beforeEach() {
        bar.getMessage = fake;
    },
    afterEach() {
        bar.getMessage = original;
    }
});

QUnit.test('can an imported module be mocked?', assert => {
assert.equal(foo.message(), fakeMessage);
});

And the actual code under test:
import bar from 'modules/bar';

let foo = {
    message() {
        return bar.getMessage();
    }
};


export default foo;

I would appreciate your feedback on this!

You will find unit tests, code, settings, project structure and setup at my GitHub page:
https://github.com/DavidVujic/blog/tree/master/es2015-testable-modules

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

What? Wait. Really? Oh no! (a post about ES6 classes and privacy)

ECMAScript 6 is here with lots of new features, one of them is the class keyword. Yes, we can now write classes in JavaScript. You knew that already, right? Happy, pappy? 

I guess that about half of the World population currently is doing an imaginary High Five, the other half is probably planning a revolution (or will they just write a function?). Class is a controversial thing in society.

I am not that thrilled about it, but classes are here and will be used. Heavily. JavaScript classes are however a bit different from the ones written in C# or Java. How do I write a property? Are the properties I add private or public? Most of the examples I've seen in blog posts and presentations look something like this:

class myClass {
     constructor(firstName) {
          this.firstName = firstName;
     }
}

Is "firstName" a private property? Nope. It is publicly accessible - everyone can read and change it. If you have ever used function constructors, the behavior will be familiar. Everything added to an object using the this. syntax will be public.

Is it obvious that classes will work the same way? I don't think it is. I think the word class itself implies that certain functionality should be present. Especially for programmers coming from C#, Java or any other object oriented language. In JavaScript, classes also can only contain methods. Private variables cannot be added in the class body in the same way we are used to in C#. This code will throw an error:

// will this work? (No.)
class myClass {
     let _firstName = ''; // illegal syntax
}

Almost private?

To make a property almost private, you could use the new Symbol data type to generate a property name and store it in a Module together with the class. A symbol is a unique value (like a GUID) and will (most likely) prevent properties from being overwritten by code that consumes it.

An example:

// myModule.js
let first_Name = Symbol();

// How about this, will it be private? (No.)
class myClass {
     constructor(firstName) {
          this[first_Name] = firstName;
     }

     get name() {
          return this[first_Name];
     }
}

export default myClass;

This won't make the property private, because all keys of an object (including symbols) can be accessed using the Reflect object or the getOwnPropertySymbols method of the current object.

Really private?

I have searched for and found the following solution to be good enough for creating private properties in JavaScript classes: using WeakMaps (also new in ES6). This data structure will keep track of your property names and keep them private (as long as you don't export them, of course). The data in a WeakMap is linked to the source object and will also be garbage collected when the source object is removed.

// myModule.js
const first_name = new WeakMap();

class myClass {
     constructor (firstName) {
          first_name.set(this, firstName);
     }

     get name() {
          return first_name.get(this);
     }
}

export default myClass;

By adding the current instance of the class and the actual property value to a WeakMap, we have the behavior of private variables. If this class is extended (inherited), the properties cannot be accessed directly, since the WeakMap only exists in the module. You can't have it all, I guess.

Is it worth it?

I don't know. Time will tell. Personally, I think I mostly will use simple Modules and export object literals. Or why not use a plain old Immediately Invoked Function Expression (including private variables and methods) instead of complicating things with classes?


Update:
@stevenlangbroek has shared a nice alternative solution. I think looks like a hybrid between a class and an Immediately Invoked Function Expression. Check it out! Private variables in ES6 classes

Yeah, we got classes now (ES6). You happy, pappy?

Since the beginning of time, JavaScript has been the class less society. Everyone had a function there. With ECMAScript 6, classes have now been added. Ah, man.

Wait, wait, wait! I actually like it. I believe the class keyword is good thing to JavaScript, mmkay?

There is quite a few frameworks out there that already have introduced classes (or class like solutions) to the language: Dojo, Prototype, CoffeScript, TypeScript ... They all have their own way of doing it. ECMAScript introduces a common way of how to write a class, and that itself is great. How can classes be useful in JavaScript?

I think it can simplify the structure of code, we can write functionality that is only accessible within a class. But then again, we have modules now. A module can export an object and keep code private. Why use classes?

Well, I think the benefit of writing a JavaScript class is inheritance (using the extends keyword). Inheritance can of course also be accomplished by creating literal objects extending other objects, simply by adding properties and methods to it. But the functional inheritance style looks kind of awkward sometimes. Writing a class that extends another class will probably make more sense. Especially for programmers used to write code in c#, java, Ruby or any other object oriented language.

However, I don't think consuming a class the traditional way is a good idea in JavaScript. I think it is an anti-pattern. Creating instances of classes using the new keyword spread out all over the code base? Don't do it! 

In sucks in c#, it sucks doing it in JavaScript too. Dependency Injection and IoC containers solve the "newing up classes problem" in c#. How about JavaScript?

Here's a suggestion.

Create your classes in ES6 modules. Export an already created instance (if you want a singleton like functionality), or export a "make" method that returns a new instance of the class.

By doing that, the consumer doesn't have to worry about if the code within the module is a class or an object literal.

An example:

// the foo module, exported as a singleton
class foo {
     constructor() {
          // constructor code here
     }

     myMethod () {
          // method body code here
     }
}

export default new foo();

// the foo module, exporting a "make instance" method
class foo {
     constructor() {
          // constructor code here
     }

     myMethod () {
          // method body code here
     }
}

let makeFoo = () => new foo();

export default makeFoo;


Using the first example, the consumer will get a baked and ready instance of the foo class. The second example will give the consumer the ability to get different instances, by calling the make function. The actual structure (currently a class) of the module is hidden, and not a part of the API.

What do you think about this? Let me know!





" - Happy, Pappy?"