The Artima Developer Community
Sponsored Link

Test-Driven Development
A Conversation with Martin Fowler, Part V
by Bill Venners
December 2, 2002

<<  Page 2 of 4  >>


A Sense of Unhurriedness

Martin Fowler: There's an impossible-to-express quality about test-first design that gives you a sense of unhurriedness. You are actually moving very quickly, but there's an unhurriedness because you are creating little micro-goals for yourself and satisfying them. At each point you know you are doing one micro-goal piece of work, and it's done when the test passes. That is a very calming thing. It reduces the scope of what you have to think about. You don't have to think about everything you have to do in the class. You just have to think about one little piece of responsibility. You make that work and then you refactor it so everything is very nicely designed. Then you add in the next piece of responsibility. I previously used the kind of approach you describe. I'd ask, "What's the interface of this?" I've now switched and I much more prefer incremental design.

Bill Venners: Well, I'll try it.

Martin Fowler: In many ways, you have to just try the process out for a little while. It's best to try it out with someone who's done it before. Just do it.

Here's an example of incremental design that I ran into when writing Patterns of Enterprise Applications Architecture Design. I needed to create an example in a pattern about associative table mappings. If you have a many-to-many relationship in memory and you need to persist that to a relational database, it requires an extra link table, so you get three tables. There are multiple ways to pull that data back into memory from the database. There is a simplistic way of pulling the data back that requires a lot of select statements to be executed. There is also a faster way to pull it back. You can just pull the data back in a single select statement. But then it's a bit more awkward to get the data out and to unpack it into the various objects.

I created the example for that pattern using incremental design. I started by writing an example that was hard-coded for three particular tables and two particular classes. I didn't think about generalizing it. I just made a very specific, concrete example work. After I got that working and had it passing its tests, I started refactoring the example to make it more generally applicable. After a bit of time refactoring, I had a general mechanism. All I had to do was write a tiny mapping class, and I could make the example work with any tables and classes. I had a general purpose structure.

I found it much easier to do the concrete example first, then refactor that to the abstract example, than to come up with the abstract example first and then apply that to the concrete case. I also found it much more calm and unhurried, even though the process went pretty swiftly. I constantly knew where I was and where I was going. I felt much more in control of the situation. I didn't have that, "Am I ever going to make this code work?" feeling.

<<  Page 2 of 4  >>

Sponsored Links

Copyright © 1996-2018 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use