« Source Code for .Net Framework Libraries to be released later this year | Home | How do you know when it’s working? »
TDD == TFD, and WWTDDD?
By indomitablehef | October 8, 2007
In recent discussions with colleagues about Test Driven Development, I was reminded of the importance of the “Driven” part of Test Driven Development. When I first heard about TDD, I naturally got excited about it. It sounds great. It’s obvious, really, once you see it. Obviously the way things should be.
But then reality sets in. Writing tests is an entirely new skill to learn, and not a particularly easy one, at that.
Think back on your first Object-Oriented development efforts. How “object oriented” were they, really? For many of us, our first attempts at OO ended up being very procedural solutions implemented in a rich object oriented programming language. In theory, we were gung-ho about OO. But we hadn’t yet transformed our way of thinking about problems into a framework that would take advantage of all the wonderful things that OO could offer.
How many of us eventually wandered off the other side of the trail? After realizing that we were stuffing square, procedural pegs into round, object oriented holes, we vowed never to make that mistake again. Every class had an interface, every object a factory, every entity an inheritance hierarchy, and we ended up with a polymorphinhericapsulatestracted mess.
TDD is much the same. It’s a new paradigm. A new world view. To really be effective at it, it must transform the way you think about software development (even in the database - but that’s a post for another day…specifically, after I’ve figured out how to do it better). I was at a conference recently (ITARC Atlanta - IASA Regional Architect’s Conference) where Scott Ambler said: “if you’re not writing tests, you’re not a professional”. Ouch. Seriously…that stings, because I know deep down that it’s true. Ouch.
My journey into TDD is far from done, and I haven’t yet earned my merit badge, at least in my own eyes. But I have learned a couple of things along the way.
1. TDD == TFD
The most important thing about TDD is that you must (absolutely must) write the test first. TDD is really TFD - Test First Development. It can be more than just “first”, but to do it well, it has to be done first. Why? If you don’t write the test first, you won’t write the test. My first two, maybe three attempts at TDD after I drank the Cool-Aid failed miserably because I did not grasp this concept. We all have time pressures (those of us that get paid to do this, anyway). When you are under pressure, and you’ve already written working software, the temptation to skip the tests (promising to come back to it later) is just too great. Under pressure, the mind looks for shortcuts, and finds them. Tests fall by the wayside, along with all your good intentions.
2. WWTDDD? (What Would Test Driven Developers Do?)
“Being TDD” is like coming to Jesus. There’s no way you can go back and atone for all the code you’ve written that doesn’t have a test. The best you can do is to start trying to do better today. If you have time to go back and write tests for something old, do it. Atone for past sins when the opportunity presents itself, but don’t wallow in guilt. But from now on, begin your day with testing. Begin every new task by writing a test. Get religion. Start by writing tests for anything new that you do, and write a test for any bug in existing code that you have to go back and fix.
I have these diagrams posted on either side of the door to my kyoobickle:
10 Ways to Improve Your Code - Neal Ford (www.nealford.com)
Introduction to Test Driven Design (TDD) - Scott Ambler (agiledata.org)
Topics: Uncategorized |
Chris Hefley (the indomitableHef) is a software developer/architect from Nashville, TN.