I’ve written about Test Driven Development before.  I’ve even written about 100% code coverage before.  And I haven’t written much about it recently because I’ve been focused on JavaScript.  But, I’ve been thinking about the 100% code coverage debate more and I have a few more thoughts on the subject.

You see, the more I practice Test Driven Development, the more inclined I am to believe that there are only three reasons for arguing against 100% code coverage.

There is Something Wrong with Your Framework

This will be the easiest one for most people to accept.  It isn’t so personal.

You see, I’ve been learning React JS and, as I’ve mentioned before, I decided to learn React AND learn to test it at the same time.  The thing that has impressed me from the outset is that ALL the code that I write is testable.  Where a lot of other frameworks are testable except for the View, React JS is ALL testable.

And this got me to thinking, if all the code you write is testable, why wouldn’t you write tests?  In fact, as I wrote in “Test Driven Learning, an Experiment”, the process of writing the tests as I go has helped me understand React JS better than if I had not.

But compare this to other frameworks where the View is basically HTML.  There is no really easy way to write tests for HTML.  At least, none that I know about.

And then there are frameworks that seem to do all they can to make it hard to test.  When I was using Ext JS 4.x, I spent two years looking for a way to make my code testable without having to have the View rendered because the way they had implemented “MVC” made loading the view mandatory.  Talk about tight coupling!  Fortunately, now that they’ve implemented MVVM, if you do this correctly, it solves these problems.

Another place where I found testing difficult was with Angular 1.  Most of Angular 1 is quite testable.  It was created with testing in mind.  But as I was trying to add a decorator to the UI Grid component, I found that testing the decorator was quite difficult.  This, I believe, said more about how the UI Grid component had been created than about how the Angular framework was put together.  But this just illustrates my point.  Sometimes, the reason you can’t test has more to do with the tools you are using than any other reason.

Then again, the problem may be you.

There is Something Wrong with Your Code

Now, arguably, in my last example, the reason I was not able to test the decorator for my Grid was because I was missing some fundamental concept related to testing decorators in general or how that related to the Grid.

The reason I say this is because the one thing I’ve noticed the more I test is this.  The more I practice TDD, the easier TDD becomes.

As I introduce testing into the organizations I work with and as I’ve grown in my own TDD skills, the one thing I’ve noticed is that when we start out learning TDD, it almost always starts out as DDT.  That is, Development Driven Testing.

This is, of course, better than not testing at all, but if you wait until after you’ve written your code, or you develop your code without thinking about how you will test it, you will almost always end up in a situation where you will have to rearrange your code to make it testable.  Untestable code is probably the single biggest reason why code doesn’t get tested.

If you were able to make yourself write your tests first, you would be much more likely to write test for everything you wrote.

This doesn’t help you though if you’ve been tasked with writing tests for all pre-existing code.  Yours on someone else’s.  In this case, the best help I can give you is to recommend the book “Working Effectively With Legacy Code” where Michael Feathers illustrates how to handle a lot of the common scenarios he has run into with various languages and how to untangle the mess so that it can be tested.  I will admit it is a tedious read, but there really is no better resource on the topic.

Lack of Experience

The final reason you might want to think that 100% code coverage is impossible is that you simply don’t have enough experience.

As I mentioned above, my own experience has been that the more I practice TDD, the easier it gets.  When I started out, I struggled to write test at all.  Then I got to a point where I would at least attempt to write tests after I’d written some code.  I’m now at the point where I’m writing tests as I code.  Soon, I hope to achieve the ultimate goal of writing test prior to writing the real code.  But even though I wasn’t writing the tests first, I can still say that the tests were driving my development because I knew at some point, I was going to have to test the code with unit tests.

But as I’ve monitored the noise on the Internet about using TDD or not.  As people have discussed how much of their code should be tested.  I wonder, “Just how long has this person been trying to tests?”  Along with that, I wonder, “Do they even want to test?”  My dad used to say, “It is amazing how much I don’t understand when it doesn’t fit my plan.” Let’s face it, for most programmers, writing tests is not nearly as much fun as writing the application.  If this is true, then aren’t you already biased against writing tests for your application?  Wouldn’t you much rather write the app and toss it over the fence for someone else to tests?  I know I would.

Now combine that with the fact that testing is hard, and you have a recipe for excusing yourself from testing as much of your code as possible.

But, if you stick with it.  If you make writing bug free code a personal challenge, you will find that the rewards are worth it.

What would it be like to be THE developer who was always working on new features because no one could find bugs in the features you programmed in the past?  What would that do for your career?

The 100% Code Coverage Payoff

I want to conclude with another story that illustrates how writing tests paid off.

I’ve been working on a resource scheduling component for the last several weeks.  The bulk of the logic is that if two resources are scheduled for the same time, I need to be able to display that there is a conflict.  It sounds pretty straight forward until you look at all the various ways items can overlap.  I’ve isolated the logic for this into a class that is quite testable and I had created a test suite with about 400 tests when I was told that along with that requirement, there were a particular set of conditions where what looked like a conflict wasn’t really a conflict.  I needed to show that there was an overlap, but I need to display it in such a way as to indicate that it isn’t a conflict.

As I sat down to add in the new logic, I realized that the path I had been going down wasn’t going to work well given this new scenario.  What I really needed to do is to do some major refactoring.  In fact, you might even say I had to rewrite most of the code I had in place.  Now, in the past, I would have been afraid to tear up all that I had done and start over because it would have meant I would have to retest all that I had already worked on … manually!  But, since I already had tests in place, I was able to 1) commit what I had done so far to version control so I could get it back if I needed and 2) rip up what I had done, rewrite and refactor so that it would work well with the new requirement and 3) retest with the tests I ALREADY had in place.  I’ve added another 100 tests for the new scenarios and I’m pretty confident that the code I’ve written does what it should and doesn’t do what it shouldn’t.

And that whole refactoring exercise took less than 7 hours.

Oh.  And I have 100% code coverage!

Over the last several months we’ve looked at several different aspects of how JavaScript deals with objects.  A few weeks ago, we looked at JavaScript Types and noted that many of the types are actually objects, while not all are.  We’ve also looked at JavaScript Objects and JavaScript Object Fields.  This has all been foundational information you need to understand prior to understanding how JavaScript Prototypal Inheritance.

No Classes

If you are coming from an object oriented background, the first thing you need to understand is that JavaScript doesn’t have classes.  Even though the class keyword was introduced in ES2015, there are still no classes.  All the class keyword does for us is formalizes what we’ve been doing for years while making JavaScript feel more like the other languages we know.

I’m not going to spend a lot of time dealing with ES2015 syntax here for several reasons.  First, it isn’t fully implemented in the browser eco system yet.  Second, most of what we do as programmers is maintain existing code.  There is a lot of existing code that doesn’t use ES2015 yet.  Third, ES2015 hides what is really going on.  I want you to understand how JavaScript works, not just be able to churn out code.

So, if there are no classes, how does JavaScript achieve inheritance?  By using the delegation pattern.

Delegation

In the object oriented world that you are probably coming from, you’ve probably heard the phrase, “Favor composition over inheritance.”  What they are really saying is, “Favor delegation over inheritance.”  So, this shouldn’t be a particularly new concept.  When you create a class that contains other classes, once the class is instantiated, when we need to call a function that the top level class doesn’t implement, we pass it on into an object that is contained by the top level object.  This is delegation.

Now, remove the classes.  All you have left are the objects those classes would have created.  This is JavaScript.  But, instead of leaving the delegation to you, they’ve provided a default delegation mechanism called the prototype.  In fact, if you’ve ever inspected a JavaScript object in the debugger, you’ve probably seen this field hanging off your functions.  The other place you’ll see evidence of the prototype is in the __proto__ field that hangs off of every object.

Default Inheritance

Whenever you create a new object using either an object literal, or a function (or the class keyword) the prototype field automatically points to the default empty object.  It is this default object that gives all of our other objects the behavior of an object.  Without this, none of our objects would have a default toString() implementation, for example.  It is the default object that gives all other object their object-ness.

Constructors

Once your head stops spinning, come back and check this out.  While we no longer have classes, we still need some way of stamping out objects that all look the same.  We already looked at one way of doing this when we discussed JavaScript Objects.

1
2
3
4
5
6
7

function A(){
    var self = this;
    self.someProperty = 'A';
    self.someFunction = function(){
        self.someProperty = 'B';
    }
}

And for most of the code we write, this is a perfectly adequate way of creating a constructor. By attaching the functions to the function’s prototype field, we can apply the functionality one more level up the tree, which gives us a certain amount of flexibility. The same code above could be written as:

1
2
3
4
5
6
7

function A(){
    this.someProperty = 'A';
}

A.prototype.someFunction = function(){
    this.someProperty = 'B';
}

Notice that we didn’t attach someProperty to the prototype.  We want the state information attached to our object.  If you did attach it to the prototype, all it would do is give the object a default value of ‘A’ but as soon as we assign ‘B’ to it, the property gets shadowed anyhow.  If you were to Object.define() someProperty so that it had a setter, which would remove the shadowing, you would also change the value for every instance of the object A when you changed it from any instance.  I suppose if you wanted to implement something that looked like a static variable, this is something you might attempt.

The key to remember here is that anything you do to the prototype is going to impact all current and future instances of the object.

JavaScript Prototypal Inheritance

By now, I hope you understand that all inheritance happens by delegation through the prototype.  The next obvious question would be, “How do I make one JavaScript ‘class’ inherit/delegate to another ‘class’?” One way you might be tempted to implement inheritance is by assigning prototypes.

1
2
3
4
5
6
7
8
9
10
11
12
13

function A(){
}

A.prototype.foo = function(){
}

function B(){
}

B.prototype.bar = function(){
}

B.prototype = A.prototype;

But all this does is make B inherit from the same thing A inherited from.  Not exactly what we wanted to see happen.

OK, you say.  I know what to do, I’ll just create a new object of type A and assign THAT to the prototype of B.

B.prototype = new A();

You’re closer and it may work a lot of the time, but if your A function that you are using to create that other object does anything, you may end up not doing what you expected.  For really simple objects, this will work, but it is a dangerous habit to get into.

What you really want to do is to use the Object.create() function.  This creates a new object without calling the constructor function.  No side effects.

1

B.prototype = Object.create(A.prototype);

But, what if that A constructor function did something important? In your B constructor function, you call the A constructor function passing it the current this pointer.

1
2
3

function B() {
    A.call(this);
}

If B takes parameter than need to be passed on up to A, you can pass those additional parameters after this in your call to call().

And that is how we make JavaScript inherit one object from another.  It is a lot of work.  This is why ES2015 introduces the class and extend keywords.  They do a lot of this work for us.

The story goes that there were two men, Joe and Frank, who were camping out in the woods when a bear showed up in the camp.  Terrified, they decided the best they could do would be to stay perfectly still until the bear left.  Hopefully, the bear wouldn’t notice them.  As the bear was poking around, Joe says to Frank, “What are we going to do if this doesn’t work?”  Frank says, “Run!”  Joe says, “You really think we can out run a bear?”  Frank says, “I don’t need to out run the bear.  I only need to out run you.”

Read More

As I’ve mentioned before, I’m in the middle of putting together a React reference app and I’m doing it using Test Driven Development.  The problem is, the standard tools for implementing ES2015 code coverage with Jest make it hard to see at a glance if you have 100% code coverage or not because of some issues with the way Jest tells Babel to do the transformations by default, the way Babel transforms the code and implements the auxiliaryCommentBefore option and the way that Istanbul parses the ignore next comments.

I’ve been working on solving this problem for the last month and a half off and on.  I’ve even posted a question about this on Stack Overflow, so I’m pretty sure no one else has a solution for this yet.  I’m not going to say my solution is the best way to solve this problem, but it is a solution, which is better than what we have so far.

Diagnostics

By default, when Babel transforms your code, it inserts additional functions into the code that it can call to replace the code you wrote that does not yet conform to the syntax you’ve used.  This code gets inserted at the top of the file and shows up in your code coverage reports as several conditions that didn’t get fired.  Yes, it inserts code it never uses because the functions have to work under a variety of scenarios.

For those who are interested in how I figured this out.  The transform results are located in node_modules/jest-cli/.haste_cache.

ES2015 Code Coverage Fix One

OK, so the standard recommended fix for something like this is to place

1

/* istanbul ignore next */

Prior to those functions.  And it just so happens that both Jest and Babel provide a mechanism for adding this comment by using the auxiliaryCommentBefore option.

Only there are two problems with this.

Problem One

If you just set the property like this:

auxiliaryCommentBefore: ‘istanbul ignore next’

Your code will get transformed so that any functions added by Babel will end up looking like this:

1

/*istanbul ignore next*/function babelFunctionHere()...

But in order for Istanbul to pickup this comment, the code needs to look like this:

1

/* istanbul ignore next */ function babelFunctionHere()...

While getting the spaces on either side of ‘istanbul ignore next’ is a simple matter, we have no real control over the space that is necessary between the comment marker and the function keyword.

Problem Two

The second problem with this “fix” is that even if modify the Babel code so that the comment gets inserted correctly, it doesn’t get inserted before EVERY function that Babel inserts.  If it inserts a group of functions, which it does regularly in my code, it only inserts the comment before the first function.

ES2015 Code Coverage Fix Two

What if we didn’t insert the functions in our code?  Well, it just so happens that we can do that relatively easily.

There is a plug-in for Babel called ‘transform-runtime’.  What this plug-in does is that it requires in the functions rather that pasting them into your code.  This way, the functions don’t exist in your code so Istanbul never sees the function block.  Pretty cool.

You can add this to either your .babelrc file or the Babel section of your package.json file by adding a “plugins” section

1

"plugins": ["transform-runtime"]

along with the “presets” section you should already have.

Remaining Issue

While using transform-runtime takes care of most of the issues, there are two functions that still don’t get covered.  In fact, when you look at the transform-runtime code, you find that they are explicitly excluded and if you include them, your code won’t transpile at all.

The good news is, it is only two functions and they both show up as

1

function _interop...

If we can get a hold of the code as it is being transformed, we should be able to do a search and replace to get the correct ‘istanbul ignore next’ string in place prior to the functions.

Well, it just so happens that Jest has the ability to do exactly that.

ES2015 Code Coverage Final Fix

I’m assuming you’ve already installed babel-jest, but just in case, if you have not, install it now.  Install it using –save-dev because we are going to want to be able to modify the code.

Quick fix:

The proper way to fix this would be to write your own version of babel-jest.  But we are going for a quick fix.  Maybe we can get Facebook to implement the changes from this post.  Meanwhile, here is what you want to do.

Locate the src/index.js file in the node_modules/babel-jest directory.  At the time of this writing, the current version looks like this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

/**
 * Copyright (c) 2014-present, Facebook, Inc. All rights reserved.
 *
 * This source code is licensed under the BSD-style license found in the
 * LICENSE file in the root directory of this source tree. An additional grant
 * of patent rights can be found in the PATENTS file in the same directory.
 */

'use strict';

const babel = require('babel-core');
const jestPreset = require('babel-preset-jest');

module.exports = {
  process(src, filename) {
    if (babel.util.canCompile(filename)) {
      return babel.transform(src, {
        auxiliaryCommentBefore: ' istanbul ignore next ',
        filename,
        presets: [jestPreset],
        retainLines: true,
      }).code;
    }
    return src;
  },
};

The first change that you want to make here is to comment out the auxiliaryCommentBefore line.  We no longer need that.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

'use strict';

const babel = require('babel-core');
const jestPreset = require('babel-preset-jest');

module.exports = {
  process(src, filename) {
    if (babel.util.canCompile(filename)) {
      return babel.transform(src, {
//        auxiliaryCommentBefore: ' istanbul ignore next ',
        filename,
        presets: [jestPreset],
        retainLines: true,
      }).code;
    }
    return src;
  },
};

You will notice that what gets returned is the resulting transform of the code.  We want to execute a search and replace on the transformed code.  So, instead of

1
2
3
4
5
6

return babel.transform(src, {
   auxiliaryCommentBefore: ' istanbul ignore next ',
   filename,
   presets: [jestPreset],
   retainLines: true,
 }).code;

What we want want to do is:

1
2
3
4
5
6
7
8

return babel.transform(src, {
  //auxiliaryCommentBefore: ' istanbul ignore next ',
  filename,
  presets: [jestPreset],
  retainLines: true,
}).code
    .replace(/function\s_interop/g,
        ' /* istanbul ignore next */ function _interop');

ES2015 Code Coverage With Jest - Summary

1. Download and install babel-plugin-transform-runtime.
2. Add “plugins”: [“transform-runtime”] to either .babelrc or the babel section of your package.json file
3. Download and install babel-jest
4. Modify babel-jest/src/index.js as indicated above.

I was once teaching a class on JavaScript to a group of C# developers when someone asked a very logical question, “Are JavaScript Types all derived from Object?” I loved teaching this particular group because they were actively engaged in the material.  So many times, when I teach, the students simply absorb what I say, but they don’t interact with it.  They never ask the question, “What are the implications of what is being said.” My initial instinct was to say ‘no’ based on my experience with the language.  But then as I thought about it later, I thought, “But when I use the debugger on what seems to be a primitive, don’t I see it as an object?”  And as it turns out, my instinct was right.  Not everything in JavaScript is an object.  Although there is quite a bit that you wouldn’t think was an object that is.

Now that we’ve covered JavaScript Objects and JavaScript Object Fields, it is time to move on to the specifics of JavaScript types.

So, why is it, when I look at some primitive values, I see them as objects?  And which types are objects and which are primitives?

Read More

Over the last year, in particular, I’ve developed a technique for developing the client side of a web application using JavaScript, HTML and CSS that has significantly improved my development speed.  Once I tell you, it will be obvious.  At least, it is to me … now.  But as obvious as it is, I rarely see this technique used on any of the applications my peers are working on.

And while this technique is an outgrowth of my involvement with TDD, this particular technique can be used with or without TDD.

Read More

If you are using one of the many frameworks that say they are using JavaScript MVVM, you might not be using it the way it should be used. Many of my clients aren’t.

This article will attempt to answer three questions.

• What is MVVM?
• What are the advantages of MVVM?
• What are good MVVM coding practices?

Read More

Long time readers may remember that I started using Ext JS about 3 years ago.  At the time, I was using version 4.2.2.  I recently started a new contract where they are using Ext JS 6.0.1.  I have to say, this version solves a lot of the architectural issues I had with the 4.x series.  But, there are still problems.

Since I’ve provided an evaluation of Angular 2 and React JS, I thought providing an evaluation of the current version of Ext JS would be appropriate since these three seem to be the main players in the corporate world.

Read More

Over the last couple of weeks, I’ve mentioned that I’ve been learning React JS.  First in the article “Reaction to React JS and Associated Bits” and then last week in my article “Test Driven Learning”. 

In the first article, I mentioned that if you use React JS, you’ll probably end up using the Flux design pattern and since there are multiple ways of implementing flux, getting a clear definition of what it is and how it should work can be confusing.  At least, I found it confusing.

And now that I’ve figured it out, I thought it might be helpful both to myself and to the programming community at large if I offered my own Explanation of the Flux Pattern.  At the very least, it will give me one more way of solidifying the concept in my own brain.  Maybe it will be helpful to you as well.

Read More

As I mentioned last week, I’ve been learning React JS over the last month or so. Up until the start of this project, I would learn a new framework, and then I would try to paste in Test Driven Development after the fact.  I would use the excuse that because I didn’t know the framework well enough, I wouldn’t be able to properly write tests for it.

But this time, I decided to do something different.  What if I wrote tests for my demo application as I was learning this new framework?  My reasoning was that learning how to test code written in the framework was just as important as learning the framework.

What follows are the lessons I learned from this wildly successful experiment.

Photo credit: twm1340 via Visualhunt.com / CC BY-SA

Read More