Get a coach to embed with the team–someone who’s got practical, hands-on expertise in implementing TDD in legacy systems.
Trying to get TDD rolling on existing codebases is hard, hard, hard. Having a guide to help the team figure out how to succeed at TDD is critical.
I couldn’t agree more.
I was once asked to work with a team to help them improve their TDD practice. Except that they weren’t practicing TDD yet.
The team had taken a TDD class and started to write as many tests as they could. They said: “our test files are very cluttered, very brittle“. Yes they were.
As the team describes what they are experiencing, it is clear that the tests are written after the feature implementation. Further inspection of the test files confirms that, with signs of copy-and-paste throughout and across several files.
Had the team stayed on that path, they’d quickly abandon tests altogether, as it was getting too hard to maintain those tests and write new ones.
By getting a few sprints of coaching, they learned to:
- refactor the existing tests
- identify flaws in the software’s current design and implementation
- start developing the mindset of test-driven design