Please watch the video

The video is three of the most respected software engineers alive all discussing the importance of delivering tests with components of code that are created. The only disagreement is on whether the tests should be written *before* any code or whether they can be written more flexibly as development occurs and after.

Just write tests. They will make your life better.

Exactly. TDD is writing tests before project code. That is what this article is about. Nobody is saying that tests are bad. I write tests in some of my projects that I feel tests help.

So you only write tests for 'some' of your projects!!!

Guess there are some people who are happy with that - must have money to burn!

It's quite the opposite. People that rely on components that I write, they could not care less if I have written them with TDD or not, as long as the work properly. But that is for components that I publish based on well known specifications.

For projects like for instance, the PHP Classes site, which is actually a real business, the great drama is to have time to implement all the features that are planed. TDD would only delay those features because more than often, simple "look at it to see if it works" is much faster and effective than writing tests first for everything.

It might be faster but if it is buggy, then no one will use that developer again.

Customer satisfaction is worth more than time to market but you have to adopt the Agile Principles for that to work not just one of the Agile programming techniques.

No you are departing from the wrong assumption that code with TDD does not have bugs and code without TDD will always have bugs. That is unreasonable.

Customers of products could not care less if you write code with TDD or not as long as it works properly.

No - you are misinterpreting me and/or I am not making myself clear.

For any given development team, the number of bugs introduced is likely to be approximately the same whatever development process they follow.

My contention is that if you leave all the testing until the team think that the development is finished, than it will take significantly longer to find the bugs and fix them; I'm talking at last a month's worth of work.

I have proved to myself and others that by taking an existing team that had been doing 'traditional waterfall' development and moving to Agile and TDD, the development is much more efficient, takes overall less time and the customers are happier.

I would dearly like to cite the global companies that I have helped but am bound by NDA - sorry

No, that is not the way I develop software. That is the waterfall model.

What I do is to integrate new parts of my software in the running application in my development environment. I do not wait to have it all finished or released to the public to have it tested.

Most of the times I just use look at it testing. I mean I run the partial implementations that I have so far to see if it works as intended. I do not even need unit test scripts for that.

For significant new features I make them available only to beta testers even before teh features are fully implemented. Only after significant testing it is launched to the whole public.

It will not prevent that bugs appear soon or later, but TDD does not prevent that either.

For instance, right now the package pages of PHP Classes are going through a totally new design that is being worked since January.

There was a design thinking process to determine what it should be. Then a non-functional prototype was presented to the testers until all aspects were covered.

Then each new feature of the new design was implemented progressively until it looked right. Right now there are some testers evaluating what is currently implemented even though it is not fully done.

So as you may see this is not the waterfall process. That is for you to see just because we do not implement TDD for most things, it does not mean that we are stupid and do not know how to do it efficiently.