7.1. Introduction

I have been programming for 30 years and most of the time I have managed quite well without test-driven development (TDD). I am not going to be mad at IT dinosaurs if they decide to just skip this chapter. You can create Rails applications without tests and are not likely to get any bad karma as a result (at least, I hope not - but you can never be entirely sure with the whole karma thing).
But if you should decide to go for TDD, then I can promise you that it is an enlightenment. The basic idea of TDD is that you write a test for each programming function to check this function. In the pure TDD teaching, this test is written before the actual programming. Yes, you will have a lot more to do initially. But later, you can run all the tests and see that the application works exactly as you wanted it to. The read advantage only becomes apparent after a few weeks or months, when you look at the project again and write an extension or new variation. Then you can safely change the code and check it still works properly by running the tests. This avoids a situation where you find yourself saying "oops, that went a bit wrong, I just didn't think of this particular problem".
Often, the advantage of TDD already becomes evident when writing a program. Tests can reveal many careless mistakes that you would otherwise only have stumbled across much later on.
This chapter is a brief overview of the topic test-driven development with Rails. If you have tasted blood and want to find out more, you can dive into the official Rails documentation at http://guides.rubyonrails.org/testing.html.

Buy the new Rails 5.1 version of this book.

TDD is just like driving a car. The only way to learn it is by doing it.

Thank you for your support and the visibility by linking to this website on Twitter and Facebook. That helps a lot!