Sometimes... you take a detour

To say it's been a while since I've touched my side project (Calm) would be a complete misrepresentation of how long it's actually been. As you can see from my last post back in... um.... 2018... it's been a little bit longer than "a while". But, that's cool, life happens and I'm back at it, and that feels good 😊.

Since I've started picking back up the pieces and hints that I left myself, I've been somewhat confused by the highly technical notes that I left behind. Current me is trying hard to remember the context of some of these notes that past me left!! Nonetheless, I'm making some progress. One string of the yarnball that I started to pull on was beginning to use an environment file for some of the application level configuration (a tenet of The Twelve-Factor App). If you're unaware of the principals behind what is described at The Twelve-Factor App, I encourage you to give their site a read. As for configuration for your app, they require a strict separation of the config from the code. Things like port numbers, database connection strings, and 3rd party api tokens.

That's all well and fine! I did hit a little bit of a snag with my unit tests gaining the appropriate load of my environment variables when running my tests through Wallaby.js though. I took a dependency on the 'dotenv-flow' npm package into my app.js file, and wrote a test that ensured it was being used and that the port I was expecting was also being used where I anticipated it should be.

Perhaps not the most useful of tests I know, but sometimes I push things to the dogmatic edge just to see if I can, and to experience what challenges there are in doing so. Lo and behold, an unexpected challenge presented itself. My port was continually getting reported as undefined, regardless of what I tried. When I ran the app on it's own via 'npm run start', the port was console.log'ed as expected. I was not as lucky from within my test suite though. I was having a hard time finding an answer, and my google foo... for whatever reason... was failing me.

That was until I stumbled on this issue in the Wallaby.js repo. The Wallaby configuration file needed to load the .env file in order to make it's contents available to my testing context apparently... like this:

'use strict';
require('dotenv-flow').config();

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

        files: [
            {pattern: 'src/**/*.js'},
            {pattern: 'app.js'},
            //list helpers for tests last, per wallaby's suggestion
            {pattern: 'testHelpers/*.js', instrument: false}
        ],

        tests: [
            {pattern: 'test/**/*-spec.js'}
        ],

        env: {
            type: 'node',
            runner: 'node'
        },

        testFramework: 'mocha',

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

        lowCoverageThreshold: 99
    };
};

Now, does my use of a .env file completely satisfy the advice given the the author(s) of The Twelve-Factor App philosophy? No, I don't believe it does. However, it is a good first step that is better than having these types of things hard coded into the application itself. I suppose the next extension of their advice would be to have CI set the environment variables on the server itself that the code is deployed to. I'll tackle that one on some other dogmatic day, lol. Did my dogmatic requirement for this project having at least 99% code coverage force me to learn something new today? It did, and that's worth the effort to me.