These contract- and test-driven development disciplines sound really good in theory, however in everyday practice they seem to offer dubious benefits.

The problem is as follows: If a software developer is deemed not sufficiently reliable when writing a program that governs the interaction inside the system, a harness called contract-driven or test-driven is placed upon that developer. What the methodology is saying to him is: “We’ve noticed that you tend to make plenty of mistakes when programming the system. In order to avoid making those glaring mistakes, we want you to stop and write a contract first. Or, alternately, stop and write a test first. That’ll make sure that the mistakes won’t happen again.”

Sounds good? Perhaps, but there is one glaring omission that had just slipped in. And the omission is: what makes us think that a person who is not competent enough to write a reliable program would all of a sudden be competent when it comes to writing a contract, or a test? If we examine those contracts and tests, we’ll see that the same omissions in logic, once found in the code, are now infesting the contracts/tests.

So we see that the only people who are capable of writing robust, reliable contracts and tests are the people who are capable of writing reliable, robust programs in the first place. And if that’s the case, what’s the point in slowing them down and forcing them to stop and write those bloody contracts/tests?

I don't agree with Alex and see the world as follows:

When you look at TDD as an XP practice in isolation then you can make many an argument against TDD. But XP as a development methodology is build-up by many levels of feedback loops (communication), which TDD is one of. Each of these feedback loops (practices) complementing each other to deliver a stunningly better result in software projects than Traditional methods (Waterfall).

On a separate note, when doing TDD and writing the test first. You are stating the problem first, then the state the solution second. In general you don't make a mistake twice.

The other interesting aspect of TDD is, as soon as you are comfortable with the TDD method of writing code. You suddenly realize that the design of your objects and components change. Your objects display better object-oriented characteristics.

In Traditional Software projects, programmers write the code and then the tester gets the software and does the testing. This time gap also means you have this disconnect between creating, finding and fixing the bugs in the code.

The other common managerial practices when the budget gets tight, is to cut some testing time. TDD tries to overcome this problem as well.

There are many more reasons I can give why TDD is good for any software development effort. In my opinion it helps you to write Quality code.

Technorati Tags: tdd xp programming

powered by performancing firefox