Article: Making TDD Stick: Problems and Solutions for Adopters

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.

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

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.

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.

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.

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.

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.

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?

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

We started on the TDD with a team. I think group discussions and pair programming with TDD coach is the best approach to get developers started on TDD. We started with some class room training and then jumped on TDD, solving specific development problems we had in hand. Management support and patience is key. Legacy code makes the process slow. But we learned How to work with legacy code along with TDD.

I have consolidated a list of TDD benefits in the following article :


www.technodeation.com/2013/08/get-started-on-te...

Great article on TDD


Online Java Training

Spam?