My TDD Journey Started Dec 6, 1999

On December 6, 1999, as an embedded developer with 20 years of experience, I attended the first Extreme Programming Immersion.  That is where I bumped into TDD. I thought: that is odd; it could not work; but what if it did? The alternative was painful, so my mind was open to finding a better way to work.

During my first 20 years, we developed software concurrently with HW and never had a place to run our code until late in the development cycle. (Guess how that went.) After seeing Kent Beck running Java code in JUint, without worrying about where the code would be deployed, I thought this could be valuable for embedded development.

Running code off-target in a test environment was my initial draw to TDD.

How did I get convinced about TDD?  I respected the people who were advocating TDD and showing others how to do it. I recognized a problem TDD could help with. I worked through some simple example exercises with an experienced test-driven developer and started to see the potential.

I brought it to work. I quickly discovered that it was revolutionary and a valuable way to develop software.  We made some really bad tests. Small changes had large ripple effects throughout the tests.  We first thought it was TDD's fault. But guess whose fault it was?  It was our fault.  We made tests that were a mess; we learned; we got better.

I continue to find TDD valuable, with many benefits beyond simply preventing defects (preventing defects is pretty awesome BTW).  I'd like you to discover how it can make your life better.

With TDD, we work in small verified steps. Here is the

• Make a list of things to test (this list will likely grow in the following loop
• Repeat until you can't think of more tests
  • Write a single test
  • Watch the build fail
  • Make the build succeed, but let the test fail (verifying the test catches wrong behavior)
  • Make the tests pass with a small change
  • Refactor to clean up any messes you've made

TDD puts mistakes in your face so you can immediately fix them.  Jokingly, I call the most popular way to program on planet Earth, Debug Later Programming.  This diagram illustrates one of the benefits of TDD, cutting down the time to fix a mistake. 

We can't really stop humans from making mistakes.  But we can catch them a lot sooner.  If you work in small verified steps, you catch many of them right away.

You can find a complete description of this diagram here.

Sign in