Testable JavaScript

Preface

You have to test your code, so why not make the process as easy and painless as possible? Client-side JavaScript is especially difficult to test properly, as we have very little control over the environment within which our code runs. Multiple operating systems, multiple versions of operating systems, multiple browsers, and multiple versions of browsers, not to mention plug-ins, extensions, different languages, zoom levels, and who knows what else, all conspire to hinder the performance of our applications. These permutations slow down, break, crash, and eat our applications for lunch. It’s a jungle out there! Server-side JavaScript gives us significantly more control, as by and large, we control the execution environment. However, Rhino and Node.js applications do not have the full gamut of mature tools, the testing procedures, and the ecosystem that other languages do. Further, the asynchronous nature of Node.js complicates testing. It is interesting that a language so intertwined with asynchronous execution has essentially zero built-in support for that mode of execution.

Regardless, testing—especially JavaScript testing—is complicated. Our best shot at taming this complexity is to take full control of what we actually do control: the code. Code exists across a continuum, from someone else’s to yours on one axis and from legacy to nonlegacy on the other.

What is legacy code? I’m a fan of Michael Feathers’s definition in his excellent book, Working Effectively ...