Recently I had a conversation with Ingmar van Dijk who is one of the most talented technical coaches out there, and we were discussing how we can do best for our clients in our testing and refactoring classes. More specifically, we had agreed that most of our clients are not working on green-field codebases and although learning testing and refactoring skills is a good first step, it is not enough to really tackle the hard problems.
We were discussing how mastering TDD, and making it an everyday habit was a multi-month process for both of us from the moment we were introduced to it, until the time we had the skills and abilities to actually perform TDD on all our code.
And we agreed that this probably one of the major reasons that the technical practices like TDD and BDD are not as widespread in the community. They are difficult and that impedes them “catching on”.
Ingmar had suggested the idea that we start with the skills needed for working with legacy code FIRST, and then perhaps go back to the intricacies of TDD and refactoring later. It seems like putting the cart before the horse…. But after a couple of weeks away from the conversation I think he is right.
Think about it – one of the reasons we don’t build a habit is that we don’t have the ability to do TDD on all our code after we are introduced to it. So it is hard to pick one regular trigger. But what if we learned a few micro-skills that would allow us to work with existing code first. And then AFTER we built the habit of writing (very simple) tests for our code before we touched anything, THEN we came back to honing our TDD skills.
This would mean, we would start with:
1) Breaking dependencies in existing code,
2) Creating characterization tests,
3) Build the code in a test-after method regularly.
Then, after the habit is built for testing all code that we work on, we go back to test-first development and refactoring and refine our skills?
Amr Elssamadisy's Blog 