Moving from "write no tests" to TDD

There was a post on an internal alias about moving a team that has not been creating any developer-written tests to one that does TDD. I wrote a reply that I think may be of more general interest...

Developers are fluent in code. I think any time you are talking to developers about engineering practices, you need to be showing them code. I think showing TDD workflow is very important. I also have stopped using the term “Unit test” as it means 45 different things before 10am.


I’m a big fan of selling the problem rather than the solution. Here are some problems that I think resonate with the developers I know:


Time Savings


Nearly every group with existing code has a section of code that either is or has been a bug factory, and most developers can make a decent estimate of what parts of new code are “tricky”. If you use TDD (or just write tests for) that set of code, you can save yourself a huge amount of time debugging. You can also factor in the difficulty of debugging certain parts of code – there is a big benefit there.




People also tend to own code that a) needs changes and b) is brittle and c) nobody understands any more, and everybody knows how much of a pain that is.


Freedom to focus on new stuff


All devs like to work on new stuff rather than fixing old bugs. If you have good tests along the way, you won’t have to be dragged away from the new stuff to fix the old stuff as often.




Everybody likes to write code that works well, nobody likes to own the bug factory. In fact, I think people leave groups to get away from something they know is a bug factory but nobody else does.




Group dynamics often push devs toward meeting a team’s definition of code complete rather than spending the time writing tests. Now, I happen to think that TDD often gets you to code complete sooner (in a tradition milestone approach), but if you’re just learning it, that isn’t the case. You need an explicit declaration that it’s okay to be spending the time writing the tests


Tests as examples


If you are creating a component that is consumed by somebody else, you can save a bunch of your time by having unit tests. Not only do you spend less time responding to email and doing bugfixes, the tests often provide very nice examples of how to use your component.



You may not that I don’t list “Design by example” there at all.  I think that design by example is a much better way to create software, but it’s an experiential thing rather than something you can put on a powerpoint deck.


Hope that helps.


Comments (5)

  1. Peter Ritchie says:

    I doubt they didn’t write any tests; they probably just didn’t call them "unit tests" or "test-driven development".

    Depending on how well the high-level design is for the software being developed, if they’re using some of Robert Martin’s OOD principles you can use the stability and/esponsibility of a package or class to decide what to begin unit testing.  For example, if a package or class is consider stable and responsible it may be best to focus writing unit test for other packages or classes. (i.e. ones considered volatile)

  2. Frank Hileman says:

    These are all arguments in favor of automated testing with good testing coverage. These arguments are not specific to TDD.

    It is easier to argue in favor of good automated testing, than to argue for a specific TDD "religion". For example, fine-grained tests (as promoted by TDD) may degrade encapsulation, as external tests access details that should be encapsulated within a sub-system. Change the sub-system and the tests break…

  3. gto889 says:

    Support you. I hope you can complete the project .. I hope that we can look at the blog。

Skip to main content