Recently I was chatting with a friend of mine and he asked if a single developer could be successful following TDD on a team that does not follow TDD. My simple answer was YES, they can. But there are a few things you must consider.....
How can they make a difference
I am a firm believer that someone practicing Agile/TDD can make a profound difference on a non-agile/non-testing (traditional, if you will) project.
Following TDD is more about your mind set and attitude then it is about the process in my opinion. Because you are following a practice that forces continuous feedback, you will actually help the team learn. This drive for continuous feedback will be what drives new information, new knowledge to the team.
Lastly, who cares if you are on an island? You can still make a difference.
Does the project get the full benefits
No, but what the project does gain is light years ahead of what it would have had other wise.
Benefits the project will gain
- Better code coverage
Even if you only can cover 5% of the code in your tests, that is 5% less code to worry about
- Increased code quality
Do I really need to explain this?
- Increased code reliability
Do I really need to explain this?
- As foundation to grow on
Because you have taking the initiate to create the test plumbing (i.e. configuration, db setup, logging setup, etc) you have reduced the barrier of entry for other developers. I have found that this barrier of entry is a common reason people don't want to start testing. I know it is lame, but I have heard it.
Will the team ever convert
This would be nice, but don't expect it. However, there are a few things you can do to increase your odds.
- Prove your code is more reliably/stable due to your tests
This is what you tests will do.
- Show them how easy it is
You will be able to show then that writing tests is not hard, that it does not double the length of time to develop the new feature. You also be able to show them how you are able to flush out uncovered bugs very early in the process, thus saving everyone time and money.
- Show them how clean your design is
Because your code will DO ONLY what is required, they will be impressed by how clean your code is.
- If all that does not work, beat them over the head with a Agile/TDD book till they cave. :)
Issues to watch out for
Because you are the only one creating tests, there are things you must be willing to accept.
- Broken Tests - Non Compiling
Don't expect the rest of the team to include your test projects in their solution. In the past I have received massive push back because they don't want to waste the time allowing the extra projects to build. Because they are not building your tests, be ready to fix various compile issues from time to time.
- Failing Tests - Compiles, but does not pass
Because your tests are not being run on any regular basis by the other team members, just assume you are going to spend a percentage of your day fixing broken tests.
Till next time,
Updated some grammar mistakes, thanks Andrew :)