Test Driven Development (TDD): What and Why

Before we dive into our first jest and enzyme tests, I just wanted to lay a little groundwork on how we're going to be doing testing in this course. We're going to be using TDD or test driven development. This means we're going to be writing tests before we write the code. The idea is that you'll write a shell version of the code, enough of the function that you'll be able to call it in your tests, but the function won't really do anything. Then you'll write the test. And of course the test is going to fail because the code that you've written, the function doesn't actually do anything. That's the red part of the red green testing. You're going to get a red or a failing test first. This is important because you want to see tests fail. It is all too easy to write tests in a way that they pass regardless of what the code is doing. So this is a really nice feature built into TDD that you always get to see your tests fail before they succeed. Once you have your failing test, then you write the code that makes your test pass. That's the green part of red green testing. Let me talk a little bit more about why I like TDD. If you're testing your code manually, that is, if you're not doing any automated tests at all, you are going to be putting some time and effort into running those manual tests. And if they fail, then you have to put the same time and effort into running those tests again in order to see that they've succeeded. With TDD, any changes you make, you still have those tests and you get to run them without any additional effort after changes. Even if you're doing automated tests, if you wait until the end of all your coding to write your tests, you're not taking advantage of the fact that you've built up tests all along that get run as the code progresses. With TDD, you end up writing better code. This is because you have to plan before you code. You have to make sure your code is planned out in order to be able to write the tests. And this makes for better organized code. And this may seem obvious, but your code is more testable. If you are writing your code with the view of testing it, then you aren't going to write any code that is completely untestable and needs to be refactored in order to make tests later. Your code will also have fewer bugs, both because bugs will be caught sooner since you're going to be doing testing as you go along and also because you'll have regression testing built in. In other words, all of the tests that you've ever written will get run every time you make a change. And finally, you'll have great code coverage because testing is a part of coding. Now, code coverage in and of itself shouldn't be your entire goal of testing. Sometimes it takes way more effort than it's worth to get that last 10 or 15% of coverage, but it is something that you want to keep in mind. And because testing is a part of coding for TDD, you generally have excellent coverage. In the next lecture, let's take a look at Create React app so we can actually start running these tests.