Most development teams have had “The Talk.” The talk about the need to have more unit tests in their project. Leads and managers like having a lot of tests, because that can be a selling point to clients and customers. The logic is typically that more tests means more coverage, and more coverage means higher quality.
However, while most developers see value in writing unit tests, few see value in performing Test Driven Development, or TDD. There are numerous objections to TDD. Everything from “I don’t know what to test until I write the code” to “It doesn’t matter when I test, as long as I test.”
In this talk, we’ll look at some common misconceptions about TDD. We’ll talk about what TDD is, and even more importantly, what TDD **isn’t.** The emphasis will be on the motivations and reasons for TDD, and will spend less time on the mechanics of TDD.