The Cost of Hidden Wires

In working on the Calm codebase one of the first things I did was wire in Wallaby.js because, well... it's amazing, and I absolutely love it. Having been in a mix of C# and JavaScript, Wallaby gives me the immediate feedback I find most useful in my TDD cycle. I do have a small love affair with the test runner, but... I will be using it as an example of how I used in a manner that gave me issues once I moved Calm into CI. I don't hold Wallaby responsible for it, I just hit a snag that needed to be addressed.

I've long held the belief that starting a project comes with it a special set of skills that I admittedly continue personal growth within. Wiring a project together to fit the needs of the overall longevity of it caries a set of unknowns sometimes that may or may not be obvious to you in the moment. And often that wiring is hidden away where you're unlikely to bump into it or have a need to go seek it out. Here is my simple example.

There is a small cost in time and a little bit of re-work that I had to pay in detangling some hidden wires in my specs. Wallaby provides a setup function that I had been leaning on until now. It was taking care of wiring some dependancies that each of my spec's needed... like hooking up chai and sinon, and it looked something like this:

'use strict';

module.exports = function () {
    return {
        name: 'Calm',

 ...
        setup: function() {
            chai.should();
            var sinonChai = require('sinon-chai');
            chai.use(sinonChai);
            global.sinon = require('sinon');
            global.next = function() {};
        },
...
    };
};

Having this configuration and wiring in the Wallaby configuration file meant that I did not have to import  those into every test file I created, which was great! That's the point of hidden wires... they are out of your way and do some special sauce to make you more productive. Once I spun up a test file, I could get on with the work that I truly cared about... my tests, without having to pull in that setup every time. I had even setup up my package.json to tell you that you could not run the specs from the command line if you ran "npm run test"... you would get the message:

"scripts": {
	"test": "echo \"Error: use Wallaby to run tests from within your favorite Wallaby configured IDE\"",
	"start": "node app.js"
}

I naturally hit a wall the second I began wiring up Continuous Integration in Circle Ci. Up to this moment, I hadn't had a need to run the tests from the command line. Remember, I'm still very early in the lifetime of this project, so I don't have a ton of code... it's still just basically a holding page with a few experiments in it that I've done along the way:

This issue could have been addressed in several ways, some involving more complexity than others, and I'm still deciding what I want to do long term. My immediate desire was to get specs running in CI... and CI deploying the application, that was it. And I was looking for the smallest commitment I could make in getting that there from a codebase perspective because I knew I would have my hands full enough understanding the CircleCI ecosphere.

In the short term, I've chosen to write a function containing all of the same configuration, moving it out of the Wallaby configuration to somewhere that can be exercised when specs are run from the command line, like this... testHarness.js is then imported into each spec file:

This may not be where things live long term, or maybe they are... the project still has a long way to go. This was a good first step though towards getting all the specs to run in CircleCi and deployments going out when things merge into the primary branch. As for the npm configuration to to run on the command line... it's now a punt to mocha :).

I haven't lost anything in my usage of Wallaby and CI works... a win win. My point in all of this is that the hidden wiring of pieces of our system often give us some efficiency or clarity in some other part of the system. The system is more scannable when reading the codebase, reducing some level of cognitive load along the way which is for sure valuable. Anytime I can reduce the amount of stuff I have to think about is typically a great thing. It can however come out of hiding as the system evolves though, and we need to be prepared for those types of moments. In my case it was a straightforward enough fix to make progress.