Test-driven development (TDD) is really a way of thinking about our code that should be part of a standard development process. It is a development paradigm that starts with tests, and drives the momentum of a piece of production code through these tests. TDD means asking the question how do I know that I have solved the problem? instead of just how do I solve the problem? This is an important idea to grasp. We write code in order to solve a problem, but we should be able to prove that we have solved the problem through the use of automated tests.

The basic steps of a test-driven approach are the following:

• Write a test that fails
• Run the test to ensure that it fails
• Write code to make the test pass
• Run the test so see that it passes
• Run all tests to see that the new code does not break any other
• Repeat

Using TDD practices is really a mindset. Some developers follow this approach and write tests first, while others write their code first and their tests afterward. Then, there are some that don't write tests at all. If you fall into the last category, then hopefully, the techniques you will learn in this chapter will help you to get started in the right direction.

There are so many excuses out there for not writing unit tests. Things such as the test framework was not in our original quote, or it will add 20% to the development time, or the tests are outdated so we don't run them anymore. The truth is, though, that in this day and age, we cannot afford not to write tests. Applications grow in size and complexity, and requirements change over time. An application that has a good suite of tests can be modified far more quickly, and will be much more resilient to future requirement changes than one that does not have tests. This is when the real cost savings of unit testing becomes apparent. By writing unit tests for your application, you are future-proofing it, and ensuring that any change to the code base does not break existing functionality.

We also want to write our applications to stand the test of time. The code we write now could be in a production environment for years, which means that sometimes, you will need to make enhancements or bug fixes to code that was written years ago. If an application has a full suite of tests surrounding it, then making modifications can be done with confidence that the changes made will not break existing functionality.

TDD in the JavaScript space also adds another layer to our code coverage. Quite often, development teams will write tests that target only the server-side logic of an application. As an example, in the Visual Studio space, these tests are often written to only target the MVC framework of controllers, views, and underlying business logic. It has always been fairly difficult to test the client-side logic of an application—in other words, the actual rendered HTML and user-based interactions.

JavaScript testing frameworks provide us with tools to fill this gap. We can now start to unit-test our rendered HTML, as well as to simulate user interactions such as filling in forms and clicking on buttons. This extra layer of testing, combined with server-side testing, means that we have a way of unit testing each layer of our application—from server-side business logic, through server-side page rendering, right through to user interactions. This ability to unit test frontend user interactions is one of the greatest strengths of any JavaScript MV* framework. In fact, it could even influence the architectural decisions you make when choosing a technology stack.