Mark Ethan Trostler - Testable JavaScript

• DRM-free ebooksuse your ebooks across devices without restrictions or limitations

• Multiple formatsuse on your laptop, tablet, or phone

• Lifetime access, with free updates

• Dropbox syncingyour files, anywhere

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. Its 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, testingespecially JavaScript testingis 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 elses to yours on one axis and from legacy to nonlegacy on the other.

What is legacy code? Im a fan of Michael Featherss definition in his excellent book, Working Effectively with Legacy Code (Prentice Hall): legacy code is code without tests. This code either will not survive or will never be touched by anyone. When the time comes to touch legacy code, it gets rewritten. Take a look at your current project; any code that does not have tests will likely be rewritten. Probably not by the author of the code, but by whoever is now tasked with dealing with iteither enhancing or bug-fixing it. Unless tests are written, this is dead code that will have to be rewritten. The code may be spectacular, but the only way it will survive is if it never causes bugs and if no one ever requests enhancements or new features for it. Even then, how happy are you to ship production code with no tests? Even if the code worked before, are you content to keep rolling the dice? Is your company, which owns the code, content to keep rolling the dice? Typically the piper must be paid, and this code will just get rewritten. Its too bad the company had to pay to have this possibly spectacular code written twice, but such is the case with legacy code.

As you can see in the matrix shown in , it is very easy for any legacy code youve written to fall into someone elses hands and be rewritten. That path is typically less painful than bringing someone elses legacy code up to speed with tests. It is very easy to move from side to side in this matrix, as code changes hands constantly, moving into and out of your purview with great agility. Moving down is the hardest path for code to take; writing tests for existing code is a job no one wants to do, and most people will go to impressively great lengths to avoid ittypically resulting in a complete rewrite.

Figure 1. Current versus legacy code

Unfortunately, moving up in this matrix happens with some regularity. Code that starts out with tests can lapse into legacy code if it falls into the wrong hands. Vigilance is required to keep tests up to date as more enhancements and features are bolted on, but this is a much simpler process than writing tests for code without any (or with very few) tests.

The Goal of This Book

This book aims to keep your JavaScript code in the lower-right quadrant of by taking a holistic approach to development. Its not just about writing tests or testing first, but rather understanding how the choices you make while coding, good and bad, will affect you (your code and your employment) down the road.

Starting with the good habits of structuring your code syntactically and semantically for testability, writing the right tests at the right times, running them regularly, and monitoring their results will keep you in that lower-right sweet spot in the matrix.

This book attempts to bridge the gap between sane development practices and JavaScript. JavaScript is a weird little language. Starting with its senseless name, JavaScript was originally used by nonprogrammers to add some interactivity to web pages. Even if real programmers used the language in its early days, the dynamics between the language, the DOM, and the browser environment took some getting used to.

As more and more professional programmers started working with the language, best practices began to be understood and codified. Tools for working with JavaScript, debuggers, test harnesses, IDE support, and more began to emerge. The language itself was modified using lessons learned from several years out in the wild. JavaScript was starting to grow, and grow up. But a lot of weirdness remains, and more powerful tools are still around the corner.

With the advent of server-side JavaScript via Node.js, PhantomJS and other applications can now be written entirely in JavaScript. Not too long ago, that was not only impossible, but also thought to be insane. No one is laughing now!

This book attempts to pull together lessons learned from decades of study and experience with testing and quality assurance (QA), and to apply those lessons to JavaScript. Almost all the examples and code snippets in this book are written in JavaScript (some Perl has snuck in there!).

Who This Book Is For

This books primary target audience is people who encounter JavaScript professionally. Beginning, intermediate, or guru-level developers are all welcome, as this book has something for everyone.

JavaScript may not be the only language you use, but you write or test significantly sized chunks of it. Someone is paying you (hopefully good!) money to wrangle JavaScript to run either in the browser or, lucky you, on the server. If you are dealing with JavaScript every day with an application of any size, this book is right up your alley.

This book is also for you if you are on a QA or tools team that must test JavaScript are right in your wheelhouse. This books aims to make testing as easy as possible, and then automate all of it. Hopefully, this book will make peoples lives easier. Thats just how I roll.

If you write only a little JavaScript, this book still has lots of good information for youespecially the chapters on complexity (). The remaining chapters still have good information within, mind you! But they probably do not directly address your pain points. A lot of pain has led to my writing this bookIve learned from previous mistakes and hard work, and so should you! Learning good habits from the start will make you much more productive and happy.