Preface

JavaScript is not only widely used to create attractive user interfaces for the Web, but, with the advent of Node.js, it is also becoming a very popular and powerful language with which to write server-side applications. In this context, JavaScript systems are no longer toy applications, and their complexity has grown exponentially. To create complex applications that behave correctly, it is almost mandatory to cover these systems with an automated test suite. This is especially true in JavaScript because it does not have a compiler to help developers. Unfortunately, it is easy to fall into testing pitfalls that will make your test suite brittle; hard to maintain, and sooner or later, they will become another headache instead of a solution. Using behavior-driven development and some common testing patterns and best practices, you will be able to avoid these traps.

A lot of people see the whole TDD/BDD approach as a black-and-white decision. Either you do not do it, or you try to achieve a hundred percent test coverage. The real world calls for a more pragmatic approach: write the tests that really pay off and do not write those that do not give you much value. To be able to take this kind of decision, a good knowledge of BDD and the costs associated with it is needed.