Retrofitting TDD to the Development Process

Every professional team out there does it (at least according to the literature), the potential benefits are huge in terms of both quality and speed, but we don’t have time for it. We’re too busy fixing bugs. Test driven development (TDD) or test first development puts the traditional waterfall on it’s head. We’re developers: we write code. Other people test our code. You want us to write tests? Then write code? Continous integration? Sounds good – I’ll get back to you when I’ve fixed this top priority user-reported bug. We’ll try it when we start a new project. That’d be more efficient than changing the way we ‘re working on our current project.

Changing the way people work is hard. It means changing habits and attitudes. We can use technological means to enforce that unit tests get written – the code repository can reject commits with less than, say 70%, test coverage. But that doesn’t stop developers writing tests after the code. Tests written after the code are more likely to pass as the developer knows exactly what a particular method does and so writes a test to match.

Test first development means writing a failing test. Consequently the code is written to make the test pass rather than the other way around – the tests describe the system functionality exactly. When you write the tests you are considering what the method does rather than than how it does it. Writing code first mixes the what and the how.

But how to change attitudes and habits? Classically there are four ways

  • Education
  • Encouragement
  • Enforcement
  • Hypnosis

The last is undoubtedly the most effective. Unfortunately it’s not very ethical to hypnostise people without their permission.

Technological enforcement is not possible (the technology can not tell if code or tests were written first); shouting and beatings are generally discouraged in modern workplaces; peer pressure can’t be applied as I’m trying to change the entire team’s attitude.

Encouragement has to be subtle and gradual. Praising someone for something they don’t want to do can be perceived as false or patronising.

Which leaves education. A one off training session is not sufficent (though it can be a good start); regular on the job training is needed. The only form this can take is one-one with each developer taking them through writing tests first on the project they are working on. If the penny drops with that developer, he can be used as an evangelist and train the next developer whilst you train another, working your way through the team.

This process can be very motivating. Developers love lots of management attention, especially if they are singled out for special attention.

  1. No comments yet.

  1. No trackbacks yet.