In my previous post I explained that you don’t need the entire team in order to start TDD. So lets see some options for the lone programmer.
The question of where to start depends upon the context you find yourself in. For example lets consider the following:
A lone programmer in a hostile organization
You are a team member (or a team lead), you tried running TDD through the team but they feel its stupid, in fact they are strongly against it. If that’s not enough your manager also think TDD is a total waste of time and is closely monitoring to make sure you are focusing on writing production code only. And the worst thing is that the organization is a strict one, no tool can be used without going through the proper channels.
Yes this is as worst as it can get and there is not much you can do (other then maybe start refreshing your CV). But still you can start with the learning parts. TDD takes some knowledge to do properly, its not enough to just decide and jump ahead. there are practices to follow tools to be learned and techniques to be adopted. I have never encountered an organization that will block a determined programmer from acquiring knowledge, even if that knowledge is not directly related to current work.
Here are some places when TDD knowledge can be gathered:
- The Art Of Unit Testing - Roy Osherove.
- Test Driven Development: By Example – Kent Beck.
- Working Effectively with Legacy Code – Michael Feathers.
- Clean Code: A Handbook of Agile Software Craftsmanship – Robert C. Martin.
Also there are numerous conventions and blogs dealing with TDD and other Agile Aspects. which deals with various aspects of agile development and some are even more specific to talking and helping with Conventions (and recording of)
It might also be a good idea to refresh on proper design principle and refactoring techniques as well. Even if you wont be able to practice TDD writing clean properly design code is always a good idea and i have yet to meet someone which object to that.