Article: Making TDD Stick: Problems and Solutions for Adopters

Posted by Abel Avram on Jan 07, 2009 06:46 AM

Community

Agile

Topics

Collaboration ,

Methodologies ,

Agile Techniques

Tags

TDD ,

Testing ,

XP

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.

Read: Making TDD Stick: Problems and Solutions for Adopters

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.
• Languages used in the real world, like Visual Basic and JavaScript, are never used as examples in unit test documentation or classroom exercises.
• 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
• Patience
• Measure
• Instill Pride
• Management
• Pair Programming
• Community
• 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.

1. Back to top

   Slowdown!!

   Jan 7, 2009 4:35 AM by david anderson

   Good post, Mark. I think the big point in here is the "slowdown". Non-TDD developers will experience a time of reduced productivity, but this obviously is a sacrifice that has to be made to improve output quality. 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.

   Reply

2. Back to top

   Re: Slowdown!!

   Jan 7, 2009 8:30 AM by Mark Levison

   Thanks David. We're in agreement "slowdown" is a key message to both Developers and Management.

   Reply

3. Back to top

   Re: Slowdown!!

   Jan 14, 2009 6:13 AM by Marcin Niebudek

   But this is only a temporary slowdown... TDD will result in better and cleaner desing, so it's easier (read: faster) to maintain the product later on and you also get issues solved faster as it's then a matter of improving some tests that you already have and go for a solution instead of rethinking everything from scrach with each defect found in the system. So it's not only the initial slowdown to get better quality but also a higher speed after few weeks.

   Reply

4. Back to top

   Re: Slowdown!!

   Jan 14, 2009 1:01 PM by Mark Levison

   Marcin - thanks for the comment. I think that we're all clear that its a temporary slowdown. For some like yourself it was only a few weeks. For others longer. 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.

   Reply

5. Back to top

   Re: Slowdown!!

   Jan 23, 2009 9:57 PM by Olivier Gourment

   Good article! A few other considerations for a TDD-champion: - 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.

   Reply

6. Back to top

   Re: Slowdown!!

   Mar 12, 2009 10:27 AM by Erick Pimienta

   Excelent article to ramp up for adopting the TDD, what about the existng frameworks either NUnit, Microsoft... etc do they allow to implement TDD in a easy way from developers stand point, could those frameworks the reasons of developers just does not get it, what are differences?. One point is to know the theory other is how to use those frameworks to take over the TDD. Regards.

   Reply

7. Back to top

   Re: Slowdown!!

   Mar 20, 2009 4:30 AM by Steve Freeman

   Of course, the irony is that every large organisation I've been in has had a steady stream of initiatives and reorganisations, each of which has cost time and effort with the promise of future benefits. We need to tap into some of that, um, optimism.

   Reply

8. Back to top

   Introducing TDD to old projects?

   May 22, 2009 7:51 AM by Guille Carlos

   I've been interested in TDD for sometime now and I've used it in a couple of situations. My advice is, you need to try it and stick with it, no matter how frustrating it is at the beginning, you will love the results. 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?

   Reply

9. Back to top

   Re: Introducing TDD to old projects?

   Jun 5, 2009 8:18 AM by Mark Levison

   I wouldn't say a story so much as an entire book. Micheal Feathers wrote the book "Working Effectively with Legacy Code", its probably the best place to start. In addition helping people out of these holes is part of my business. I can be reached mark at pure agile dot com

   Reply

• Older >