I’ve jumped into existing TDD code bases before. I think I look at the code when I’m trying to understand the general structure, and look at the tests when I’m trying to make changes. So I guess, to think of it physically, I have the larger structure of the code behind me, and in that context I have a unit test in front of me which is the gatekeeper to the next thing I want to change. Er, or something like that.

That makes me wonder about TDD and learning an existing code base. I’m writing a book on RubyCocoa, planned to introduce TDD fairly early, but have kept bumping it to later and later in the text. Some of the reasons have nothing to do with the topic of this post, but others may. Part of what I have to do with the book is explain how and why a large, complicated framework makes sense – how it hangs together as a whole – and the tests somehow seemed to get in the way. Maybe because they focused too much attention on the context, not enough on the concept?

That may not be true. I used TDD from early on in my previous book, which was about teaching Ruby to novices, and it worked just fine. But it does make me think about “tests as documentation”, something that’s never quite worked out for me. How can we make what is mostly a historical trace of a development process into a teaching text without a whole lot of tinkering and rewriting?

(If that’s even important: in a long-lived collocated project, nobody might ever need to approach the code base alone. They’d always be paired with someone who knew it and could speak what the tests didn’t say. Things are different with open source, though.)

I recently read an blog post¹ describing a cognitive justification for test driven development. I think the topic is interesting. In doing TDD, there are a variety of reasons for why we write tests first, and it isn’t always to ensure correctne…

Breaking the expert mindset can work both for pairing and TDD. I’ve found a real (and constructive) tension between an ingrained habit of approaching problems by thinking about structure and pattern (blame the musician!), and the context-driven imperative of test-first (”this is what the code wants to look like” – thanks to Paul Dyson for this!).

I don’t think in either case this is guaranteed, though – we’ve all got experience of groups descending rapidly into group-think, and there’s no reason to believe that – if we write our tests first – the way the relationships and responsibilities in the code evolve will necessarily be that different from the last time we did it. In either case the onus is on the individual to allow themselves to be challenged out of their well-worn grooves – I’ll concede that promiscuous pairing helps (just so long as the nature of the pairing practice is understood by both, which is of course not guaranteed…) but fundamentally, individuals and groups don’t change without needing to, wanting to, and reflecting.

When you do TDD, the context is right there staring you in the face over and over again. Each change that you make is in the context of code you or someone else have written, and programming becomes more akin to sculpting or sensitive gardening, an activity where you have to look at what you have and make a decision about what to do next.

To me, that’s the core of it.. getting people to pay at least as much attention to what is there as they do to their ideas of what should be there.