TDD: Feasible to handle?

[Dirk Schnelle]

Hi Lasse,

In current development projects I made the following experience:

When the project starts, developers also start developing tests. But as the project continues the developers have less time to maintain their tests and turn to pure hacking.

This is espacially true, if there are "only" simple bug fixes that are discovered by the customer.

As a consequence, the tests and the code are out of sync.

Do you provide some tips to avoid this?

In fact this is a question, if it TDD is feasible to use in (espacially in fixed price) projects.

Dirk Schnelle

[Lasse Koskela]

Originally posted by Dirk Schnelle:
When the project starts, developers also start developing tests. But as the project continues the developers have less time to maintain their tests and turn to pure hacking.

This is espacially true, if there are "only" simple bug fixes that are discovered by the customer.

As a consequence, the tests and the code are out of sync.

Do you provide some tips to avoid this?

Adopting TDD (or pretty much any other engineering practice) requires discipline. There's no way around that. You can increase your chances of success by increasing your awareness of aspects such as the kind of behavior you've observed. I talk about a number of such things in chapter 12. However, they're really just pointers because the reality is much more complex and you'll always need to adjust your response based on your observations and perception of the situation.

Originally posted by Dirk Schnelle:
In fact this is a question, if it TDD is feasible to use in (espacially in fixed price) projects.

Yes, TDD is feasible to use in projects, fixed price or not. As I said above, it's not about the technique as such but rather about the discipline of the developers in question.

[Jeff Langr]

Lasse,

Congrats on the book! I'm looking forward to reading it.

Have you ever come across a (modern) environment where you would not recommend the team do TDD?

Regards,
Jeff

[Stefan Bell]

I would like to add on to Jeff's question: Do you think TDD makes for a slower development cycle?

[Jeanne Boyarsky]

Originally posted by Stefan Bell:
I would like to add on to Jeff's question: Do you think TDD makes for a slower development cycle?

Slower than what? Not testing at all? Testing after?

[Jeff Langr]

Originally posted by Stefan Bell:
I would like to add on to Jeff's question: Do you think TDD makes for a slower development cycle?

My experience is that TDD shortens the overall development cycle.

Not unit testing at all, or taking a test-after approach, takes less time when we are able to design and code perfectly. :-) In all other circumstances, TDD is faster when done appropriately.

Jeff

[Stefan Bell]

Originally posted by Jeanne Boyarsky:

Slower than what? Not testing at all? Testing after?

My question which was not very clear, would be to write the tests after. That is still a preferred method of many of my developers. I have never required that they use TDD but do require that they write unit tests.

[Stefan Bell]

Originally posted by Jeff Langr:


My experience is that TDD shortens the overall development cycle.

Not unit testing at all, or taking a test-after approach, takes less time when we are able to design and code perfectly. :-) In all other circumstances, TDD is faster when done appropriately.

Jeff

Thanks Jeff.
Do you know of any documentation that I could use to illustrate this point?

SB

[Lasse Koskela]

Originally posted by Jeff Langr:
Have you ever come across a (modern) environment where you would not recommend the team do TDD?

No, I haven't encountered a modern environment where I wouldn't consider TDD useful and beneficial. But there's a but.

I have encountered environments where I haven't considered it a feasible target to adopt TDD. These have typically been environments with a legacy of decades and technology from the stone age, the developers being new to the concept of "automated test". In these environments, I'd be quite happy with getting even a test-last or system level test automation practice getting traction.

I have also encountered environments where I haven't considered TDD (or even unit testing) being the highest priority. In other words, I've considered improvements in product and/or project management being something they should first look into.

[Lasse Koskela]

Originally posted by Stefan Bell:
Do you think TDD makes for a slower development cycle [compared to test-last]?

On the short term, test-last can seem faster but in my experience that's an illusion. The illusion breaks when you continue forward and start fighting against the inferior design, the bugs that survived because of insufficient tests, and incomprehensible tests that take forever to figure out.

This is just my perception, of course. There have been studies on the productivity effects of TDD but the problem is that none of those studies are what I'd call reliable. Besides, every other study seems to give the opposite results.

[Dirk Schnelle]

There have been studies on the productivity effects of TDD but the problem is that none of those studies are what I'd call reliable. Besides, every other study seems to give the opposite results.

That sounds interesting. What are the aspects that make you think a study is not reliable. Seems to be a bit vague at this point. Probably it makes sens to name answer this by an example.

/dirk

[Allan Halme]

Originally posted by Dirk Schnelle:

When the project starts, developers also start developing tests. But as the project continues the developers have less time to maintain their tests and turn to pure hacking.

I've seen this happen a couple of times and in these cases the fundamental reason for developers ceasing and desisting from writing and maintaining unit tests is that they, the developers, didn't see value in writing and maintaining them. I, on my part, wrote and maintained them as far as I could and for the code I was writing, but it was a real uphill struggle as I was really the only one doing it. And it was my "fault" that in that situation, I didn't manage to convince or show the other developers of the value of the tests. It also didn't help that when we inherited the code base all the existing unit tests mainly tested for the success of setters and getters, which set a really horrible example for the other developers, none of whom had done unit testing or TDD before.

So it really ultimately boils down to the skills and goals of the development team and the techniques they put to use.

[Jeff Langr]

Originally posted by Lasse Koskela:
No, I haven't encountered a modern environment where I wouldn't consider TDD useful and beneficial. But there's a but.

Thanks Lasse!

[Jeff Langr]

Originally posted by Stefan Bell:
Do you know of any documentation that I could use to illustrate this point?

Greetings Stefan,

I've written a bit about why TDD can help you go faster, using anecdotal claims, at both informit.com and developer.com. I've not seen any real research on this. The problem is that it's not very easy to take into account all the things that TDD impacts:
- time spent comprehending existing code
- ability to make changes on brittle or rigid code
- ability to sustain software over longer periods of time
- ability to accommodate changing requirements over time
- time spent debugging (or, money spent on help desk staffing, or on lost customers)
- defect rates
Many of these elements could be lumped into "quality of design."

I'm not saying that TDD is the best solution to all these challenges, but the benefits I've seen it provide in these areas is to me more than worth any slight additional initial coding effort.

From a pure coding standpoint, I've found that having tests allows me to "just code" faster, particularly once the system is past the initial "building block" phase. The ability to refactor means that I'm more likely to build tiny reusable methods and classes, which in turn improve my speed with respect to writing additional code.

Jeff

[Sonny Gill]

To add to what Jeff says -
Writing tests first also clarifies your understanding of what you are trying to build.
In other words, most of the time, if you can't see how to write a test first for the code that you are going to write, then you probably don't fully understanding what you are trying to build.
Having a policy or culture of TDD forces developers to ask more questions to fully understand what they are trying to build before they start coding a solution.

[Jeanne Boyarsky]

Originally posted by Allan Halme:
I, on my part, wrote and maintained them as far as I could and for the code I was writing, but it was a real uphill struggle as I was really the only one doing it. And it was my "fault" that in that situation, I didn't manage to convince or show the other developers of the value of the tests.

Another approach is to set a smaller goal for yourself. Can you get your teammates to agree that they will fix any unit tests that they break, but adding new ones is optional. If so, this gives you time to create some tests yourself (as a good example) and letting people see their value in regression testing. Than you can start having people write tests.

[Lasse Koskela]

Originally posted by Dirk Schnelle:
That sounds interesting. What are the aspects that make you think a study is not reliable. Seems to be a bit vague at this point. Probably it makes sens to name answer this by an example.

Well, the last two studies I've seen were made based on a total of 8 teams, only one of which consisted of industry professionals and the rest were undergraduate students. And the only statistically significant difference between the teams that tried TDD and the teams that did test-last was in a code metric called LCOM (lack of coherence in methods), which is far more sensitive to general competence of the programmer rather than whether he did test-first or test-last. I just don't see that being a study that I should take seriously.

[sanker san]

Will TDD help to reduce the defects? On an average, how much percentage can we reduce when compared to normal flow(testing after development)

Thanks in advance.

[Lasse Koskela]

Originally posted by sanker san:
Will TDD help to reduce the defects?

Yes, it does.

Originally posted by sanker san:
On an average, how much percentage can we reduce when compared to normal flow (testing after development)

I have no idea of averages. All I can really say is that for me the reduction has been significant enough that I no longer question the value of doing it.

[Stefan Bell]

Originally posted by Jeff Langr:


Greetings Stefan,

I've written a bit about why TDD can help you go faster, using anecdotal claims, at both informit.com and developer.com. I've not seen any real research on this. The problem is that it's not very easy to take into account all the things that TDD impacts:
- time spent comprehending existing code
- ability to make changes on brittle or rigid code
- ability to sustain software over longer periods of time
- ability to accommodate changing requirements over time
- time spent debugging (or, money spent on help desk staffing, or on lost customers)
- defect rates
Many of these elements could be lumped into "quality of design."

I'm not saying that TDD is the best solution to all these challenges, but the benefits I've seen it provide in these areas is to me more than worth any slight additional initial coding effort.

From a pure coding standpoint, I've found that having tests allows me to "just code" faster, particularly once the system is past the initial "building block" phase. The ability to refactor means that I'm more likely to build tiny reusable methods and classes, which in turn improve my speed with respect to writing additional code.

Jeff

Thanks Jeff.
I am trying to give my team a reason to move forward in TDD. Most are doing test last (which was an effort in itself to get them to unit test). Now to take the next step. Most are smart people and if they see documentation that it will help thier development skills and create a better product, they will try it. Some will do it because I ask them to but all ammunition that I can get for the ones that don't want to try it is good.

Thanks again...

[Jeff Langr]

Originally posted by Stefan Bell:
I am trying to give my team a reason to move forward in TDD. Most are doing test last (which was an effort in itself to get them to unit test). Now to take the next step. Most are smart people and if they see documentation that it will help thier development skills and create a better product, they will try it. Some will do it because I ask them to but all ammunition that I can get for the ones that don't want to try it is good.

Greetings Stefan,

I've found that everyone has their own personal hurdles, and the job of a coach is to help them work to the point where they have convinced *themselves* that they want to do TDD. It usually requires hardcore pairing for a number of sessions. Most people see the light.

I think you're right. You won't convince them that they should embrace TDD with words alone, so the important thing is to convince them that they should at least *try it*. You should insist that they try it wholeheartedly--have an open mind, have a coach to help them do it well, and do it for a decent enough period of time.

Jeff

[Jeff Langr]

Originally posted by sanker san:
Will TDD help to reduce the defects? On an average, how much percentage can we reduce when compared to normal flow(testing after development)

There are teams who have been XP (including TDD) that have reduced defects to less than 10 per year against decent sized systems. I believe Martin Fowler claims one of these.

Jeff

[Lasse Koskela]

Originally posted by Jeff Langr:
There are teams who have been XP (including TDD) that have reduced defects to less than 10 per year against decent sized systems. I believe Martin Fowler claims one of these.

I believe one of our teams at Reaktor Innovations built a system for one of the biggest corporations in Finland that has had a total of two defects found in production since the first deployment. I certainly don't consider the legendary zero-defect software being mission impossible. Difficult, perhaps, but certainly not impossible.