I’ve just published a new software package on Github and NPM called test-ease which is ready to use if you need a simple, straightforward, lightweight testing framework. I think this is going to be a great solution for testing small and medium software projects, and I plan to use it in a couple of other projects I’m working on now. In fact, that’s why I wrote it.

I wouldn’t blame you for wondering why I wrote my own testing framework — after all, there are so many pre-built options out there ready to go. Let me show you with an example. Here’s what a fresh install of Jest in an otherwise empty directory looks like:

Yes, that is 275 packages made up of 3,540 files taking up over 16MB (generously counting the actual data size and not the size on disk) for a testing framework which, according to its website, has a “focus on simplicity.” Now, don’t get me wrong, I do actually quite like Jest’s syntax and how easy it is to get started with. For the right project, I think it’s a great choice.

I just want to point out the absurdity of how normalized this kind of dependency hell has gotten. It’s like nobody learned anything from the whole left-pad debacle, or maybe we took away the wrong lessons. One of the principles that kept coming up in my college computer science classes was “minimize coupling, maximize cohesion.” I strongly believe that one of the biggest problems in software engineering today is that this idea is largely ignored. Intricate, tightly coupled systems are the norm now, and when one tiny, obscure, unrelated building block somewhere breaks, millions of people around the world often feel the consequences. Software supply chains are a thing now, and they are more vulnerable than ever.

When a system is overly complex, it is likely to break in unpredictable and inexplicable ways. That’s why the IT Crowd trope of “turning it off and on again“ is so true in reality: with a hopelessly complex system that no one person fully understands, the first troubleshooting step to try usually really is a complete reset and a quick prayer that the issue was just temporary “gremlins” or something to that effect.

There’s a better way, and it was invented in the 1960s. Something I strive for in every piece of software I write is to get as close as possible to understanding everything that’s going on. That’s not always totally practical, but using a minimum of dependencies and simplifying as much as possible makes it a lot more likely, and makes it way more likely that I will thoroughly understand most of what my software is doing.

That’s where test-ease comes in to make software testing for small-to-medium-size projects a simpler task. Counting the README, the copy of the MIT license, the self-test script, and even package.json, the initial release of my framework is just over 0.1% the size of Jest with all its dependencies at the time of this writing. With a modern Threadripper and 128GB of RAM, you might not have to wait for quite as many seconds to install a traditional testing framework as I do on my aging Core i7-4790. In an age of 20TB hard drives, a few megabytes could be seen as insignificant compared to the flexibility and features you get in return. If you need all those features, absolutely go ahead and use Jest or Mocha or something similar. However, if you need a framework to run a few dozen tests on your homegrown Node app and you want to be able to read through the entire codebase in less than half an hour, now you have an option for that too. You’re welcome.