Wallaby.js Blog
Integrated Continuous Testing Tool for JavaScript

The Holy Grail of JavaScript Testing

My last blog post was about mighty knights of JavaScript testing, today it’s turn of the Holy Grail of JavaScript Testing.

knights

So I was watching this video the other day, and while the purpose of the video is to demonstrate how to set things up and get started, the end of it really reminded me about the pain I had to experience before I created wallaby.js.

If you watch the last minute of the video (from 3:14), you’ll surely notice that

  • to accomplish one simple task of writing a test, the author had to switch context several times between three different applications - terminal, code editor and browser test page;
  • code coverage is missing (and when present, may add the fourth application to keep switching to);
  • larger application will take a few seconds to build and a few more to run your tests.

Of course, there are a few solutions that may get you closer to a better workflow, such as a file watcher via gulp or grunt, karma with webpack plugin, etc. I have previously spent many hours trying to get closer to what I think the modern productive automated testing workflow should look like.

And I failed. There are just too many moving parts to stitch together - even if or when it all works, the whole thing is far from satisfying my list of requirements. It’s like trying to build something from a pile of LEGO bricks with a few non-matching and few missing bits and pieces.

lego

Don’t get me wrong. I love small tools, when each one is doing one thing well. It’s nice to be able to choose a testing framework, a module bundler, language dialect, a transpiler, an application framework, a code editor, etc., as opposed to be forced to use a monolith from a single vendor.

But once I’m happy about each and every part, I want them to work together smoothly. When I write my code with tests, I’m doing just one thing - I am writing my code with tests. So I need a tool that would allow me to to do this one thing well.

Also, to be fair, my expectations for the modern and productive testing workflow are pretty high. I sometimes do JavaScript TDD, sometimes I am using some mixed approach where I write some of my code first, but either way:

  • I’m too lazy to save files to run my tests. Code changes should be enough as a trigger.
  • I don’t want to wait too much for my tests to finish running. Running the whole suite when a single test or file changes just doesn’t cut anymore.
  • I don’t like to leave my code editor to see the feedback from my tests. Hate apps/context switching. Docked tool windows or a console/terminal/browser next to my code editor - are still distracting.

For those of you who write tests, everything I have listed probably sounds like the Holy Grail of JavaScript Testing, doesn’t it? Well, it exists now. And yes, it supports everything I have mentioned, Webpack, node.js, ES6 and ES7, React JSX, TypeScript and CoffeeScript, many other technologies and their crazy combinations.