Article: Making TDD Stick: Problems and Solutions for Adopters
In this article, Mark Levison addresses the difficulties encountered by developers willing to adopt TDD, the reasons why many start using TDD but give up after a short period of time, and what could be done to help developers make TDD a habit.
By doing a survey among developers, Mark noticed that:
- People find it hard to TDD on their own, when they don't have much experience with it.
- TDD Education so far has focused too much on problems that are simpler than the real world.
- More time is needed to experiment and try without the usual pressure of releasing software at a specific date.
- The average code base is full of legacy code and no training was provided in how to improve this code.
- There is never enough time to learn – there is always (artificial) pressure to ship product soon, and so we can't take the time to improve.
After discussing the reasons behind his survey findings, Mark proposes several solutions:
- Classroom Training
- Online Training
- Instill Pride
- Pair Programming
- Coding Dojo
- Reading Workshops
- Periodic visits from a Coach
In order to make TDD a habit, Mark’s conclusion is that the developers need patience, practice, support from their management, a multipronged approach and their colleagues’ help.
This is a pretty obvious point for TDD heads, but it's difficult to explain this to non-technical folk. For example, give me a 3 month period of reduced output and hopefully in 6 months, quality & defect counts will improve. That's a leap of faith! Necessary, but a hard sell.
So it's not only the initial slowdown to get better quality but also a higher speed after few weeks.
The key however is communicating this expectation to management and team members so they don't panic when they see it happen.
Also I can tell you in a large corporate env it seemed to slow us down a bit longer. Maybe because of the crufty nature of the existing code or maybe because we'd all become old and stiff.
- FIRST, understand the reluctances and adopt the same point of view. This will give you a common understanding and baseline for discussions. In order to convince the skeptics, you need to fully understand where they stand and why they are standing there.
- Test data is a very real and complex problem. It falls in the category of things that are not addressed in "examples of using TDD are too simple and do not reflect real life problems". How to maintain test data that is relevant and exhaustive enough for tests to be meaningful and cover real life cases, while keeping maintenance/refactoring costs down? Until your team has figured this out for themselves, it's doubtful that they will "enjoy" developing automated integration tests.
- Focus on quick wins first (easy to implement, providing real benefits). Have testers and developers sit together for a while to work on designing tests first. Developers should appreciate that, hoping it will reduce the numbers of bugs found later.
- print out and distribute the most relevant chapters on TDD from Agile leaders.
- if things are not looking good -and before reluctance has built up to the point of no return!- design and agree on TDD standards for your team and *DO* impose a 3-month mandatory-no-exceptions-do-TDD period to the whole team. After this period, discuss the findings, and hopefully by then they should all be convinced (with some subtle guidance, coaching and assistance on the way!). If a justification is required in order to avoid a revolt, then show them the talk by Ken Schwaber (on Google Video, entitled "Scrum et al."). Explain to them that they have nothing to loose (this will require understanding and support from management), but everything to gain from having one more tool in their toolbox.
One point is to know the theory other is how to use those frameworks to take over the TDD.
Introducing TDD to old projects?
I do have a problem and I am looking for some advice. I am now on this project where the coding is almost "complete" but there is not a single test written for the code!! Has anyone ever implemented TDD into a project that has already been "completed"? What would be the best approach for this? What was your experience? Should we just start writing test as the bugs start coming in?
The team is not experienced at all in TDD and the project is close to deployment. My fear is that as bugs come in and being that the team is not experienced in TDD, its going to take a longer time to fix the bugs, possibly causing the client to get upset.
Any stories on this issue?
Re: Introducing TDD to old projects?
In addition helping people out of these holes is part of my business. I can be reached mark at pure agile dot com
I have consolidated a list of TDD benefits in the following article :
Online Java Training