Jeremiah Flaga My thoughts and experiences on programming, life, atbp.

TDD Quotes

I believe, like Uncle Bob Martin does, that, today, TDD (or Test-Driven Development) is one of the hallmarks of professionalism in the software development world.

So I would like to convince myself and my fellow software developers to embrace TDD. :smile:

Ergo, these quotes…

Uncle Bob Martin (So… You want your code to be maintainable?)

Nothing makes a system more flexible than a suite of tests.


Good architecture and design are important; but the effect of a robust suite of tests is an order of magnitude greater. It’s so much greater because those tests enable you to improve the design.

“This can’t be overstated. If you want your systems to be flexible, write tests. If you want your systems to be reusable, write tests. If you want your systems to be maintainable, write tests.

“And write your tests using the Three Laws of TDD.”

Michael Feathers (Working Effectively with Legacy Code)

Code without tests is bad code. It doesn’t matter how well written it is; it doesn’t matter how pretty or object-oriented or well encapsulated it is.

“With tests, we can change the behavior of our code quickly and verifiably. Without them, we really don’t know if our code is getting better or worse.”

Uncle Bob Martin (TDD Harms Architecture)

“The idea that the high level design and architecture of a system emerge from TDD is, frankly, absurd. Before you begin to code any software project, you need to have some architectural vision in place. TDD will not, and can not, provide this vision. That is not TDD’s role.”

However, this does not mean that designs do not emerge from TDD –– they do; just not at the highest levels. The designs that emerge from TDD are one or two steps above the code; and they are intimately connected to the code, and to the red-green-refactor cycle.

It works like this: …”

Micheal Feathers (The Deep Synergy Between Testability and Good Design - NDC 2010)

“If your code is not testable, then it is not a good design.”

“In general, every time you encounter a testability problem, there is an underlying design problem.”

“There is a big difference between mentally knowing about coupling and feeling the pain of coupling… But when we actually write tests, we feel concrete pain. The concrete pain is not because testing is difficult, it’s because we need to change our design.”

“I can have all these interesting thoughts about design. But if I write my tests first, it’s an instant concrete reminder of whether things are actually aligned pretty well with good design principles or not.”

“If you’re finding trouble testing things, reconsider your design and end up with something better.”

Uncle Bob Martin (Expecting Professionalism - Kuppelsalen, Copenhagen - December 15, 2015)

TDD minimizes debugging time.

TDD is a good way to make code example for the programmer to read.

TDD makes writing code fun.

TDD makes you write decoupled code (decoupled code == testable code) which can make the design of the system better.

TDD gives you a suite of tests that you trust with your life. And when you have that suite of tests, you can do many other things like cleaning code and cleaning the design.

Nothing makes code more flexible and maintainable than having a suite of tests by a huge order of magnitude.

You give me an application that is beautifully designed but there’s no tests. I’ll be afraid to touch it. It will rot.

You give me an application that is badly designed but has a comprehensive suite of tests. I can make the design better because I have a suite of tests.

A suite of tests is more important than a good design.

Harry Percival (Preface of “Test-Driven Development with Python”)

I’ve lost count of the number of times I’ve thought “Thanks, tests”, as a functional test uncovers a regression we would never have predicted, or a unit test saves me from making a really silly logic error. Psychologically, [TDD] made development a much less stressful process. It produces code that’s a pleasure to work with.

Michael (GeePaw) Hill (How TDD and Pairing Increase Production)

… the hard part of programming is the thinking, not the typing…

TDD increases your production because it serves as a thinking-aid. It limits back-tracking and gold-plating and it reduces code-study and debugging. Pairing increases your production for the very same reason. Two developers together don’t type as fast as two developers separately, but we don’t care: the bottleneck is the thinking, and pairing and TDDing both improve it.

Other useful TDD quotes

TDD isn’t something that comes naturally. It’s a discipline, like a martial art, and just like in a Kung Fu movie, you need a bad-tempered and unreasonable master to force you to learn the discipline.”

— Harry Percival (from Chapter 1 of “Test-Driven Development with Python”)