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.
Manuel Lemos - 2014-06-12 02:47:27 - In reply to message 3 from Steve Ash
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.
Steve Ash - 2014-06-13 01:27:34 - In reply to message 6 from Manuel Lemos
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
Manuel Lemos - 2014-06-13 02:54:19 - In reply to message 7 from Steve Ash
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.