I’ve recently switched to a point where I end up doing a significant amount of coding in JavaScript, which has been both fun and frustrating. I’ve resolved as part of that to stay out of Visual Studio as much as possible, and to try as many different tools as I can to see what resonates. One of the things I’ve been struggling with as part of that transition is finding a satisfactory TDD workflow; we have suites of tests written in mocha, that are ran via gulp tasks. The output from gulp goes into the console, so it’s not like we’re blind, but compared with the full-blown IDE experience, this is a pretty poor feedback loop.
When programming in C#, I’m a big fan of NCrunch, a continuous test runner that compiles and runs tests on every keystroke. It’s a really great way to work, with constant feedback on changes, and it means I get into a rhythm of red/green/refactor quite effortlessly. One of my team introduced me to Wallaby.js, which gives me that same workflow in JavaScript, which I’m really excited about. Like NCrunch, it’s not free, but after a quick trial I was happy to invest in the more productive workflow it enables. The way to look at tooling is not just at the ticket price of buying the license, but at the time/money savings that will come from working more effectively every day. It’s a crazy false economy to balk at paying a couple of hundred dollars for a tool that will save hours every week!
From what I’ve picked up so far, Wallaby.js works in a fairly similar way to NCrunch; it has a change detection algorithm that tries to map changes in tracked files to tests that might be affected, and runs these at every opportunity. I’m using VS Code as an editor, and that gives green/red dots in the margin, showing coverage, and there are some very cool integration features. There’s a little server built in, with a web based interface to show the test status – I guess that would be more use in a less powerful editor. What’s really nice though is that test failures have hyperlinks – in the console output and in the browser, which redirect the editor straight to the affected area.
Probably my favorite thing so far is the inline display of console log information – just by dropping in a console log, a pretty-printed representation of any object is shown over the code. This gives a really fast feedback loop without resorting to debugging – it’s early days, but seems well worth a try!