- Everybody knows what TDD is
— why, it’s when you write your tests first! - Everybody knows what CI is. Heck, it’s when you have your builds automatically triggered by check-ins
- Everybody knows what MVC is. It’s when you monkey the Ruby On Rails framework
- Everybody knows what DDD is. It’s when you have Repository<T> that encapsulates your CRUD operations
Of course, real definitions of these are very far from the common understanding.
Specifically, when it comes to TDD, it’s not just writing your tests first, it’s also writing your integration tests before the functional tests.
Say, you have a bunch of classes implementing a multi-step process and you want to add a step to it. Say, each of your steps is a separate class. You know what the requirements for the step are, and your first impulse may be to start writing the tests out. Wrong! First of all you should write the integration tests that specify how your new step fits into overall process. This will naturally force you to mock your step (or “stub” or “double”, you know what I mean) in order to inject the mock into the process class. This will in turn require defining the interface of the step (assuming all steps are different). And that, kids, will force you to consider things that you would likely miss if you started with the functional test for the step itself.
That’s what I mean by early integration: integrate before it’s written. TDD = IDD.
