From the course: JavaScript: Test-Driven Development (ES6)

What is TDD? - JavaScript Tutorial

From the course: JavaScript: Test-Driven Development (ES6)

Start my 1-month free trial

What is TDD?

“

- [Instructor] So the first thing that you're probably wondering about test-driven development is, "What exactly is it?" The answer to this question is so simple that it might be hard to imagine that test-driven development is one of the most controversial concepts in the software development field. Test-driven development means that you write tests for your production code before you've actually written the production code. And that's it, nothing more, nothing less. TDD is exactly what the name implies. Software development where tests are written before the actual software. This means, for example, that if we were writing a function that converts inches to centimeters we'd write a test that calls our function with a series of different measurements and tests the output of our function before we've even written our inches to centimeters function. And only then, one we have our tests, do we actually write the code to make those tests pass. This contrasts with, for example, writing the tests for your software after the production code has already been written, or, as is most often the case, just not testing your software at all. At first glance, test-driven development might seem like a strange way to write software. After all, what's wrong with writing our tests after we've written the production code? Well, let's put it this way. Tests exist to ensure software quality and writing the tests first ensures that the tests exist in the first place. It's no secret that the tests aren't necessarily the most fun part of your code to write, and writing them first, before any production code has been written, before any management has the chance to see your production code and insists that it's good enough and that you don't need tests, writing the tests first ensure that your code base is well-tested from the very beginning, instead of pushing the task of writing tests off into the distant future, which, in most cases, never comes. So then, as we continue on in our exploration of test-driven development, there are a few things that you should keep in mind. The first is that the ultimate goal of test-driven development is software quality. Without this goal in mind, test-driven development has very little meaning and probably won't help you that much. Throughout your career in software development, you'll likely meet many people who have lost sight of this goal and complain about having to write tests all the time, or who follow the test-driven development rules mechanically, but have no idea why they're doing it. Obviously, neither of these viewpoints is very helpful. In my experience, the best way to ensure that you keep doing test-driven development and actually enjoy it, is to keep in mind that each test you write is meant to be a step toward ensuring that your code base is robust and maintainable. The second thing to keep in mind is that it's possible to write both good tests and bad tests. We'll go into much more detail about this in later videos, but it's an important thing to keep in mind. Just because all your code is supposedly covered by tests doesn't mean that those tests are actually helpful. In many cases, it can be like somebody that goes to the gym every single day, but while they're there, they don't actually do anything. In the same way, it's possible to have tests that appear to be doing something and appear to cover all your production code, but, in fact, they really don't do that much. We'll talk about how to avoid this later on. And the third and final thing to keep in mind is that, as I mentioned before, test-driven development is a pretty controversial topic in the software development field. While, at the end of the day, everyone's goal should be to ensure code quality, a lot of people have their own ideas about how best to accomplish this goal, and most will defend their view very passionately. The viewpoints you'll see in later videos, which I'll present as facts, are really my own point of view regarding TDD, and I'm sure you'll find people who will disagree with them. That's just the way TDD is. Anyway, that's just something to keep in mind as you continue with the course.

Contents