Test-driven development

- [Instructor] Test-driven development is used for small scale to fine scale feedback. Acceptance tests offer small scale feedback at the scope of days. And unit tests provide fine scale feedback at the scope of minutes. In the year 2000 when I was a younger software developer working at a startup with a group of friends, we worked in an environment of long hours and rushing to get the code done. Sometimes the code barely worked but we were forced to ship it to customers anyway. It didn't feel right. A few of us bought copies of Kent Beck's book, "Extreme Programming Explained" and we read it. One of the practices we adopted was test-first programming, or as it's more commonly known today, test-driven development. And once we got the hang of it, we were writing the best code we had ever written. Test-driven development is the practice of writing automated tests first before you write any production code. In Kent Beck's book, he calls the practice test-first programming. It's the same thing as test-driven development. I usually say test-driven development because that term is more commonly used. There are two scales of test-driven development and extreme programming. The first is acceptance tests. An acceptance test is an automated test that validates that you've completed the implementation of a user story. The time scale of an acceptance test is days, stories are small enough that we can get them done in a few days or less. You write the acceptance test and within a few days, it passes. The second scale of test-driven development is unit tests. A unit test is an automated test that validates a single focused small element of the behavior of a story. The time scale of unit tests is minutes, you write a unit test and within a few minutes, it passes. Acceptance tests and unit tests work together to help you implement user stories effectively. Test-driven development works because testing your code is good. It finds bugs that we want to fix before we deliver the product to our customers and to other stakeholders. But many team's test after they've written the code. The programmers hand off the software to a separate group of people, the testers. By handing off the software, some information is lost. The testers don't understand the intent or behavior of the software the same way the programmers do. Their mutual misunderstanding leads to inefficient communication and rework. While the testers are busy testing, the programmers move on to write code for the next story. And by the time the testers find bugs, the programmers don't remember the details of the code they had written. They interrupt the work they were doing and they spend extra time trying to get their heads back into the old code. It takes longer to fix bugs afterward than to fix them while writing the code the first time. To amplify the benefits of testing and mute the pain of testing after we've written the code, we take testing and turn it up to 11. We do it all the time and we call it test-driven development. TDD ensures that we get stories done, we're not done until all the tests are green, until all the tests pass. Quality gets built-in, TDD prevents us from writing too much code, from writing unnecessary features from sugarcoating or gold-plating the code. As soon as the tests go green, we stop writing code. Test-driven development operates in three steps, it's kind of like a three-step dance. The first step is to write an automated test that fails. When this happens, we say the test is red. Then we write just enough code to make the test go green, until the test passes. Finally, we improve the code, simplifying it to make it easier to work with the code in the future. When you begin working on a new user story, start by writing an automated acceptance test. Many teams use tools like Cucumber and Selenium to help them write and run automated acceptance tests. Run the acceptance test to make sure it's red, to make sure it fails, then write a unit test for the first tiny part of the story. Many teams use tools like Junit to help them write and run automated unit tests. Run the test to make sure it's red, to make sure it fails. Then write just enough code until the test goes green, until it passes. Finally, improve the code, keeping that test green. Rerun the acceptance test, if it's green, congratulations, you completed the story. If it's red, repeat. Adding additional unit tests to making them turn from red to green as you go. When the acceptance test itself goes green, the story is done. Commit the code and the tests and start working on a new story. And of course, when you start working on that new story, you'll begin by writing an acceptance test that goes red.