My path into the woods of Test Driven Development (TDD) was several years in the wandering, and in fact I'm still wandering there. I'm oddly writer-ly today, so let's just review that a little. Maybe it will throw off some sparks you can use.
I came to TDD through a kind apostolic tradition. In the late '90s, I was very active as a learner in the design patterns movement. One place, outside of usenet, where you went if you were into that, was the Portland Pattern Repository, aka c2.com.
For the uninitiated, c2.com was the world's first wiki, invented by Ward Cunningham. It was the inspiration for Wikipedia itself, and for the many X-pedia's that provide so much amazing free crowdsourced value in the internet, a.k.a. the world's largest library.
It was also a very happening place. I made several lifelong friends there. Over time, a new thing started to appear in its pages, Extreme Programming. Simply put, I fell for it completely, absolutely, and without demurral. It was love at first sight with me and XP.
Laugh with me, please: I was every fiery-eyed spittle-emitting robe-wearing disciple-prophet you could imagine. The worst part is this: I wasn't 20 years old, when fevers like this often grip folks, I was *40*.
Believe me, I was all in. :)
Believe me, I was all in. :)
So when TDD emerged as part of the XP package, well, I was all in on that, too. I started doing TDD immediately, was already experimenting by '99.
In my early TDD, the problems I approached using it were, well, toys. We did "katas", and preached them, like the bowling game, or roman-to-decimal, or various string manipulation exercises. And TDD in settings like that is awesome.
Meanwhile, though, in the day job, the problems I was approaching were of increasing complexity. They were not toys at all. So, as corrupt as the next guy, I *preached* TDD everywhere all the time, but I *used* TDD only near the bottom of the dependency tree. Only in toys.
Outside of these minor problems, I approached my software problems more or less the same as I always did. Partly by the seat of my pants, partly by the design principles from the '80s, partly by the stuff I learned in the patterns movement.
My TDD was kind of stymied, frankly. Those other ways to think about problems seemed to make more answers faster, and I've always believed that shipping more value faster is the mission.
(I was somewhat less rabid, too, tho still involved. As both XP and I continued to mature, we went through a lot of changes. The XP I practice these days is different from what I tried to do back then, in both detail and spirit.)
But at some point, I began to sense a way forward. There were two factors at play. The classic design principles were part of it. And my sense of myself as a human in a body was part of it.
Classic design principles, nowadays we often encapsulate them into SOLID or such, seemed to be creating designs that were, in some sense, more toy-like than naive or untutored efforts. The particular decomposition created by thinking of them was yielding more toys to TDD.
And my increasing sense of myself as not just an infinitely powerful abstract memory-machine, but a human in a body with serious limitations, it seemed more obviously beneficial of TDD when I got to use it more on the toys thrown out by classic designs.
Ever so slowly, I got better at problem decomposition. And the better I got, the more TDD'able toys I got.
And then I discovered a remarkable thing. Not only could I TDD a toy faster than I could write one w/o TDD, but when I *combined* TDD'd toys, I could *combine* them faster using TDD, too.
For the last decade, I've increasingly seen the design problem as "how do I turn this non-toy into a bunch of combinable toys so I can TDD them all?"
That's not an easy or obvious thing to do, by the way. I have gotten better at it, a lot better, but I'm not worried that I'm going to run out of things to learn anytime soon.
So I've been learning, doing, and teaching TDD for 20 years. And yes, preaching it, too, though I like to think I'm a lot less rabid than I was when I started. :)
I wish the world were full of great sources of TDD wisdom, so you could undertake my path in considerably less time. There are some, but not enough.
Joe Rainsberger, James Grenning, James Shore, Jeff Langr, all of them have produced a lot of great material about grown-up TDD.
You can also approach it by combining your own experiments, to give you hands-on TDD, with modern object-orientation theory.
Martin Fowler's work, in print or online, will send you off to a thousand others. Eric Evans in Domain Driven Design. Cockburn's Ports & Adapters, AKA Hexagonal Architecture, lots of books about the SOLID principles. These are all headed the same direction TDD heads.
My own site has some TDD material on it, and some of it is unique. But I'm not the person to write the magisterial TDD book. Though my content is inspired by what I learned about change through TDD, I am nowadays more concerned with talking about change than about code.
Anyway, that's the path I took. Your path could be shorter, and I hope it is. As you work your way through, each time you hit an un-TDD-able case, think about what might make it TDD-able.
