Category Archives: tdd

Test Driven Development – 10 years later

Michael Feathers and Steve Freeman have a really good video talking about the phases TDD went through over the last few years. I just want to highlight the summary of their presentation.

  1. Professionals test their code.
    And when they say ‘test’, I truly believe they mean writing automated tests. Nothing manual.
  2. Separate what from how.
    What you’re testing should be set apart from how you’re testing it. For example, my colleague Mark recently spoke a little about how setting up a test correctly can sometimes turn into noise and reduce the readability of your tests. One way to avoid the noise is to use Builders.
  3. Automatic tests confirm features.
    I’ve heard people say things like, “I had to go back and test some of the features from last iteration because something broke this iteration”. If we had a suite of automated tests (be it functional, integration or unit), we could avoid situations like that.
  4. It’s a change in culture.
    And it still is, surprisingly. Even after test years, TDD is still a lesser known truth in some organizations. Heck, even the understanding of what a unit test is in shockingly lacking.
  5. “Working” isn’t good enough.
    A lot of times we say things like “I tested the code, and it’s working.” So what exactly does ‘working’ mean? Does it conform to the business’ expectations? Does it perform well? Another colleague of mine, Phil, wrote about the 3 Things Agile Teams Should Care About – what does it mean to be done?. Let’s forget about being Agile for a moment and just focus on getting a particular functionality working the way as the business expected consistently.
  6. Listen to the tests.
    What should you do if the tests are failing when you run the build? What should you do when the tests fail on the continuous integration build? We should listen to them. Tests are a feedback mechanism. They ensure the integrity of our system and we need to make sure that we pay attention to them at all times.
  7. A working system provides feedback.
  8. Focus on intent.
    What is the intent of the test that you’re writing? Is it expressed clearly in the method name? Are we just testing getters and setters or are we testing the behavior of the code?
  9. When you’re lost, slow down.
  10. It’s not only about testing.
  11. Legacy code is code without tests.
  12. Understand the principles behind the practices.
    Agile advocates individuals and interactions over processes and tools. Behind every practice is an intent. We should understand the intent first instead of blindly following the practice lest we fall into the trap of using a practice for a sake of using it.