[roryokane]

This experiment is not very rigorous. The Q4 2011 change in the proportion of UI bugs could be caused by the addition of back-end code with little UI (such as maintenance tasks), or by an upgrade to the bug tracking software that encouraged grouping multiple UI bugs into one bug report. And the author didn’t calculate whether TDD slowed down their work – it is not clear that TDD is better if it avoids defects but also increases development time.

You can find more rigorous studies on whether TDD actually works on Google Scholar: http://scholar.google.com/scholar?q=test-driven+development+...

[jphpsf]

Thanks for the feedback. I will checkout this link, it looks like there is a lot of interesting resources.

Regarding the first part of your comment: I don't think that is the case. We don't usually add backend code without UI (I don't have a measurement for this unfortunately). Our bug tracker or tracking method has not changed since we first installed Trac in 2007.

TDD definitely adds more development time (especially in the beginning where you have to learn the practice and put test frameworks in place). However, I think it's good because I see it as a good investment: you spend time upfront writing test instead of spending more time afterwards troubleshooting broken software. Even better, the test suite can catch regressions long after a feature has been implemented, so you get even more value then. That really helps as a development team grows.

[freditup]

My thoughts too. It seems logical to suggest that TDD would reduce the number of bugs in the product that's being tested, at least somewhat. However, the true question may be if the time spent writing those tests (longer that the time spent writing code?) is worth it when looking at the number of problems it prevented.

I believe the practicality of TDD depends on too many factors to make statements about it in general. Is your project well defined (good for TDD) or a cool little idea that changes and morphs every day or two (bad for TDD). Is it large scale and complex (good for TDD) or quite simple (TDD may be a waste of time here). There are more factors of course too.

[jphpsf]

Thanks for the feedback. See my comment to roryokane above about the time spent on testing.

I agree with you about the practicality of TDD. For instance, recently, I was prototyping an upcoming feature involving a new library. The feature was quite different in terms of functionality (compared to the existing features). In this case, I did not use TDD as the prototyping was morphing (to use your words) quite a lot and I was trying to learn more about the library.

[qznc]

I also dislike these percentage graphs, where you cannot see how "100%" changes. Maybe the server team fired their best programmer and their bug rate went up without any changes to the UI code.