Published: April 30 2014

My readers already know that I'm in the midst of writing a book about TDD. One thing I deemed worthwhile when rethinking the test-driven state of the art is collecting opinions form those who have been practicing TDD for quite a while -- and no, I'm not talking about DHH. When doing the interviews - some asynchronously via email, others on Skype - I learned a lot, and I'm sure you will too.

So, here is the first episode (of at least six)...

Ron Jeffries is one of the very early pioneers of Extreme Programming and one of the original signees of the Agile Manifesto. Ron has written a few books about XP and development practices related to it.

You can follow his activities and contact him on

Q: When was your first contact with TDD and what did you think about it at the time?

RJ: That must have been in 1996 on the C3 project. I was willing to try it, because Kent Beck is a very convincing guy. I was probably of the opinion that it wouldn’t help much because I figured I was already a great programmer.

Q: What did eventually convince you that TDD is a worthwhile approach?

RJ: Doing it and paying attention. I found that it changes the work from something like standing cards on end to stacking them up the right way.

Q: What has changed in the way you practice and teach TDD since the early days?

RJ: I suppose I try to sell it less, because I try less to sell anything. I just show people what I do, explain how I do it, explain why I do it, and leave it up to them.

Q: Do you apply TDD differently now than you did it in the beginning? Do you use smaller or bigger steps?

RJ: I use smaller and smaller steps. I am of course always thinking but i let the code tell me what to do, not my design theories. Except when I do the opposite.

Q: Do you approach dependencies with different tools or changed tactics (think doubles, stubs, mocks)?

RJ: As a member of the “Detroit School” i do not use test doubles as a matter of course, though I might use one to disconnect from a database or to represent some larger collection.
Instead, I let the objects grow in place, testing them all as they grow.

Q: Are there situations in which you consider TDD not to be the right approach for developing software? If so, what other techniques and approaches would you recommend in those situations?

RJ: I find TDD difficult when writing software that affects the real world directly. If one’s base system calls just move objects or other “physical” behavior, I find it hard to test with TDD because there is no place to intercept and check the behavior without it happening. I find it hard to use TDD if there is no existing framework and the system is too rudimentary to make building one easy, for example with no reflection and no objects. In that case, I go in small steps and print out intermediate results. I find that I do not often check them other than visually. In rare cases I might write a little TDD-style test that checks an expected result. I never use a debugger. In most systems I don’t even know how.

Q: What do you think is TDD's relevance in today's world of lean startups, functional and concurrent programming, continuous delivery and mobile everywhere?

RJ: It’s still the best way I know to program. Where applicable — which is almost everywhere — it helps the code grow smoothly, it tends to produce simple but good designs, and it keeps me from having to stand cards on edge.

Many thanks, Ron, for answering my questions!

Other episodes of the series:

blog comments powered by Disqus