Test Driven Development (TDD) - Intro

Test-driven development (TDD) , is an evolutionary approach to development which combines test-first development where you write a test before you write just enough production code to fulfill that test and refactoring.

Understand that TDD has the same two elements. A piece of application logic, a unit, and a test for that logic. But it turns the process completely around. What test-driven development asks of us as developers is to write the test first before we write the application logic. That might sound counter-intuitive, if not indeed impossible, you may say now but I can't exactly test a method I haven't written yet !! Actually, you can. And in test-driven development, we do.

And not just once or twice, but all the time. We will write tests that attempt to instantiate an object where we haven't written a class for that object yet. We will write tests that call a method that doesn't exist. And we will run those tests. And the first time we run those tests, they should fail.

Depending on the language, they may not even compile. Or they might run, and then tell us, well, I can't find this method, I can't find this class. But we want the test to fail. Because after all, if it doesn't fail, we have some other kind of problem going on. And this is the fundamental first step of everyday test-driven development.

The core distinction between doing TDD and not doing TDD. That before we write any new code, we first write a failing test. And only after it fails, do we write the application logic to pass that test. And we write the minimum necessary code to just pass the test. One thing it immediately removes is the common situation where we create a new class or a new methodand end up staring at a blank screen trying to juggle in our heads all the things this might need to do today and tomorrow and in the future.

All this speculative code that we're trying to come up with that is quicksand for every developer. No, just pass the test. This one test. It keeps us focused. This gives us clarity on exactly what we're doing at any one point. Don't do anything more than pass this small testand this is what is meant by test-driven development. The tests drive our development. So TDD is not just development that uses unit tests. Test-driven development, as a process and technique, is all about the priority and the position that we give to those unit tests.

So why TDD?

A significant advantage of TDD is that it enables you to take small steps when writing software. This is a practice that I have promoted for years because it is far more productive than attempting to code in large steps. For example, assume you add some new functional code, compile, and test it. Chances are pretty good that your tests will be broken by defects that exist in the new code. It is much easier to find, and then fix, those defects if you've written two new lines of code than two thousand. The implication is that the faster your compiler and regression test suite, the more attractive it is to proceed in smaller and smaller steps.
Next Post »