Introducing TDD: How would you do it?
Posted by Davy Brion on August 26th, 2008
In about 2 weeks, our Belgian ALT.NET group will give a somewhat large presentation on what ALT.NET is and some of the important concepts and practices. As a part of that presentation, i’ll give a 10 minute ‘lightning-talk’ about TDD. I’ve already got a bit of an idea as to what i’m going to say, but i figured i should ask my readers for some input.
So, if you had to give a short talk (remember, only 10 minutes) about TDD, targeted to an audience that has little to no experience with it, or may not even know anything about it, what are the things you’d really want to highlight? And what are the things that probably aren’t worth mentioning for such a short talk?
Or for those of you who have little to no experience with, or knowledge about TDD, what are the things you’d like to hear if someone were to introduce the concept to you in about 10 minutes?
August 26th, 2008 at 11:18 pm
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!
August 27th, 2008 at 2:14 am
I think your presentation is targeted towards people like me. I started TDD about 3weeks back after reading about it here. then trying it out with VS testing unit. I am currently working on windows service application but writing unit test now gave me a good insight on refactoring and its help me code faster than old way of stepping through thousands lines of codes.
My point is unit test has an edge over the old way of debugging classes and methods.
It has help me understand more on how i can create a library with out even knowing what the presentation layer will be. e.g. windows forms, console or web application and even mobile UI.
but am still exploring on testing and have started using NUnit.
Good Luck
August 27th, 2008 at 7:43 am
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.
August 27th, 2008 at 8:59 am
I agree with Matt; one of the big benefits of writing tests first, is that you think about the API of your classes.
In fact, you’re writing a test and this means you are the first consumer of your code. You are forced to think about how the interface of your classes should look like and this helps you -imho- creating an explicit interface.
August 27th, 2008 at 9:05 am
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
August 27th, 2008 at 4:20 pm
Check out http://dimecasts.net/ for a bunch of .Net related 10 minute screen casts, there isn’t one on TDD as yet (AFAIK) though.
Your talk is 10 mins, you might want to think about sticking with the Unit Testing available in Visual Studio and only mentioning NUnit / MbUnit / … as an endnote.
August 27th, 2008 at 4:22 pm
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
August 27th, 2008 at 8:40 pm
You would probably want to mention that TDD is not about testing, but about driving the (OO) design of your application.
August 28th, 2008 at 7:22 am
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
August 28th, 2008 at 5:46 pm
TDD really clicked for me when I started using ReSharper heavily. It allowed me to write non-existing code first in the test and then quickly generate classes and methods from the code in the test. So, literally, I am writing the test first. Most of the confusion I have seen around TDD is that people just don’t know where to start. This style of coding really answers that question. Of course, you should not have to rely on tooling to do TDD, but for demonstration purposes it really makes things clear.
August 28th, 2008 at 7:48 pm
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.
August 28th, 2008 at 8:06 pm
very true
September 7th, 2008 at 5:21 pm
[...] Introducing TDD: How would you do it? [...]