Dennis’ 17 Laws of Test Driven Development

About 14 years ago, I got inspired by a series of posts written by (Alt) .NET veteran Jeremy D. Miller]. Now, with many years of both good and bad experiences practicing Test Driven Development, I thought it is the time to honor Jeremy by capturing my own “laws”. It goes without saying that using the term law is an exaggeration and principles or heuristics cover my intend much better.

Nonetheless, these are the “things” that have helped me avoid shooting myself in my own foot.

1. Don’t practice Test Driven Development according to the books. Sure it’s a great technique to design testable software and control your dependencies. Yes, it forces you to think about the behavior of the subject-under-test. And indeed, it can lead to tests-as-documentation of your domain. This does not mean, however, that you should always start with a test. Especially when you’re designing new code, often, you first need to sketch out the class responsibilities, flesh out the details and then refactor the code so you can continue with a test-first approach.
2. Don’t bother trying to agree on an exact definition of what the difference is between unit or integration tests. Just accept that you need tests on different levels (e.g. class, component, module, API, UI) that are complimentary. Arguing about which one is better is a non-sensical waste of…