Introducing TDD: How would you do it?

I think the biggest realization for me when beginning TDD was that the benefit of the tests is secondary. The real benefit is all of the side effects that come from writing the tests first, and writing testable code. Don’t get me wrong, it’s important to have good tests in order to refactor effectively but a lot of people tend to look at TDD as simply a means to test a project, not actually design a project.

Also, you should set up auto-correct to capitalize ‘I’ Good luck on your presentation!

Yup, it should focus mostly on all of the benefits you can get out of it. In 10 minutes you can’t really get into how it should be done, so it’ll mostly be a sales pitch i guess.

@Lookman

wow, i’m glad i got you to start experimenting with TDD . If you have any questions, feel free to email me. I can’t promise timely responses, but i’d like to help when i can.

yup… another big benefit that i’d like to mention is that doing TDD prevents you from writing code that won’t be used anyway. You don’t often hear people stressing that advantage, even though it’s a big one imo

not sure if it’s worth getting into details of the testing frameworks… i think it will be more important to stress the benefits and try to clear up some misconceptions

i’ll definitely talk about how important it is to design, but i wouldn’t go as far as saying that it’s not about testing. The tests are important to keep around for regression testing, ‘proving’ that the code works, and for refactoring safely

I have referred a couple of people to : Why you should write tests before code . I think it covers a lot of the benefits of testing.
One thing I would like to add to this list, is how testing raises CollectiveOwnershipOfCode. This is an important value in my experience. Not only from a clean source code viewpoint (many minds see more than one), but also from a project management viewpoint. Unit tests allow a developer to let go of his source code. It is the responsibility of the developer making a change not to break the tests. In real life this allows f.i., developers with a lot of domain knowledge to define tests that other people can implement. No need to check if somebody broke something, the tests will tell you. Better yet, they will tell the developer new to the project what went wrong. Thus explaining to him how the application works. The flexibility this gives a team for switching people around on different assignments is a serious benefit of this way of working.

The following paragraph out of =”Ward Cunningham’s OOPSLA ’92 Experience Report, using (and introducing) the metaphor of technical debt always helps explaining things to the more financially minded people I find.
Another, more serious pitfall is the failure to consolidate. Although immature code may work fine and be completely acceptable to the customer, excess quantities will make a program unmasterable, leading to extreme specialization of programmers and finally an inflexible product. Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite. Objects make the cost of this transaction tolerable. The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object- oriented or otherwise.