Test Driven Development (or TDD) seems to mean a lot of things these days. I’ll admit that until recently, my understanding of the term was not entirely solid. I’ll also admit, that I’m still learning a great deal about the term every single day.
I’m going to start of a series of posts that talk about TDD, reaching into my understanding and my experience. The focus will be on the theory and the processes involved. Why they are important and what they relate to. When complete, hopefully this will serve as a great starting point for anyone wanting to know about TDD, and might even help argue a business case to move towards using it.
None of it will be particularly ground-breaking I’m sure, but because writing about a subject helps us understand it - that’s what I’m going to do. So…
I’m going to start with a few assertions:
- TDD is not writing unit tests.
- TDD should involve writing unit tests.
- TDD is not the sole responsibility of a developer.
- TDD should be the responsibility of the organisation.
I’ll cover some of these points in separate posts in time - I want to get on with describing the process of getting your first test in place.