Jens Schauder is software developer since 1997. He loves software development for the constant challenges and constantly changing environment. A great chance to learn and teach. He is also blogger, author of various articles and speaker at conferences. Jens is a DZone MVB and is not an employee of DZone and has posted 81 posts at DZone. You can read more from them at their website. View Full User Profile

TDD: Do We Really Have To Do It?

04.19.2012
| 10858 views |
  • submit to reddit

Many really smart people tell us we have to use TDD if we want to create code that is worth a penny. For example take this article about TDD by Uncle Bob (one of the moderate ones). He describes the benefits of TDD in paragraphs like this:

If all your code works every minute, how often will you use a debugger? Answer, not very often. It’s easier to simply hit Ctrl-Z a bunch of times to get the code back to a working state, and then try to write the last minutes worth again. And if you aren’t debugging very much, how much time will you be saving? How much time do you spend debugging now? How much time do you spend fixing bugs once you’ve debugged them? What if you could decrease that time by a significant fraction?

But the one thing he does not provide is anything close to a proof. He offers his own experience, which might be distorted for all kinds of things.

Yet with a practice so simple (note: I didn’t write easy) as TDD and so many people advocating it one would like to see some proof of the benefits of TDD. After writing a little piece about opportunities for more research in software development I was recommended this the book: Making Software: What Really Works, and Why We Believe It. It is highly recommended for anybody interested in what works and what doesn’t work in software development. Just be warned it is a little harder to read than Harry Potter

There actually is a chapter about TDD in it. The result: Not a clear win. I’m not even trying to put the details in here, but the result is basically: Although they tried they couldn’t prove TDD to be as effective as many people claimed. But they also showed it is not as costly as many people claimed. And I think they mist at least one point: TDD can teach you a lot about software development and software design on the micro level.

So what is the answer to the question in the title: Do we have to do TDD?

Nope, don’t think so. There are alternatives, like writing your tests after the code. But I recommend TDD to everybody to try it at least for some time. Its a great chance to learn a lot.

Published at DZone with permission of Jens Schauder, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Nick Wiedenbrueck replied on Fri, 2012/04/20 - 2:27am

Thanks for this article Jens.

I agree, that the truth lies somewhere in the middle of it. I've been doing TDD for some (not too long) time now and the real benefit of it is rather the improved code quality than a reduced amount of bugs. So one could say that once you grasp how to write good code, there is not much benefit in doing TDD anymore. I have to say, though, that the quality of my code is still better when I do TDD as when I don't. So I do find TDD is useful to improve code quality and to get flexible, readable and maintainable code most of the times. There are some exceptions, though, where TDD doesn't buy you that much.

Mladen Girazovski replied on Fri, 2012/04/20 - 2:17am

Nope, don’t think so. There are alternatives, like writing your tests after the code. But I recommend TDD to everybody to try it at least for some time. Its a great chance to learn a lot.

TDD will let you write testable code, writing tests after the code will not necessarily lead to code that is easy testable, making it harder to write tests.

Apart from that TDD is fun :)

 

Wojciech Kudla replied on Fri, 2012/04/20 - 7:46am in response to: Nick Wiedenbrueck

Maybe you're not practisising TDD properly. It does reduce the number of bugs, because large number of them can be discovered at build- rather than runtime.

Arnon Rotem-gal-oz replied on Fri, 2012/04/20 - 8:53am

Uncle Bob (and many others) tell you that TDD works for them- what proof do you expect? if you find these people credible than you can try that (it isn't that you commit for life or anything) and then if you don't see the benefits move to other techniques.

Anyway, regarding empirical studies you can take a look at this article http://www.infoq.com/news/2009/03/TDD-Improves-Quality  in inforQ 

 

Arnon 

Dapeng Liu replied on Fri, 2012/04/20 - 11:50am

be pragmatic, there is no silver bullet.  

Yagiz Erkan replied on Fri, 2012/04/20 - 12:08pm

What is the alternative? Not writing unit tests at all? Then, IMHO, TDD wins in producing higher quality product with more readable code (or better designed code).

Jeff Langr replied on Fri, 2012/04/20 - 12:22pm

Nope. You don't "have to" do TDD unless your team says you have to. All you "have to" do is build product. 

The product I've built (or helped build) on (real) systems has always been of higher quality than that where TDD was not employed. There are of course challenges and questions of cost vs value.

Here is a list of a number of studies (including the one referenced above that was summarized at InfoQ):

http://biblio.gdinwiddie.com/biblio/StudiesOfTestDrivenDevelopment

I do TDD because I find it enjoyable *and* effective for a few reasons--not just because it can significantly minimize defects, but also because it makes life easier for me as a programmer. Like many developers, hearing a few testimonials wasn't enough to take on TDD initially. I had to learn for myself how and why it mattered. For those wanting to learn TDD, it helps to find the guidance of someone who can help you avoid the myriad ways of doing it poorly.

Attila Magyar replied on Sat, 2012/04/21 - 3:24am

And I think they mist at least one point: TDD can teach you a lot about software development and software design on the micro level.;

And this the main reason people should try it out. Everyone uses OOP, but still it is not a well understood programming paradigm. There may be other ways, but I found TDD is very effective in learning about software design.

The idea of TDD may sounds simple, but practicing it is hard with full of challenges. I definitely recommend reading a good book (http://www.growing-object-oriented-software.com/) about it before start.

Jonathan Fisher replied on Sat, 2012/04/21 - 5:24pm in response to: Dapeng Liu

That's about the best piece of advice, ever.

Fabrizio Giudici replied on Sat, 2012/04/21 - 5:35pm

To me the really important thing is to write tests, and of course you can write them after the code. There's a major pitfall, as pointed out by others, that it's harder to write tests after the code since usually without TDD the code is less oriented to tests. 

There's another important point. If you first write the code and then tests, when the project starts to slid beyond schedule the team will try to recover time by skipping tests rather than realizing that the estimates were wrong. They have the false impression of being able to compensate, but are just building up technical debt. This leads to a disaster in the medium-long term. So, in the end I can sum up the point by saying that it's more likely to get a better test coverage by using TDD.

Personally I work mostly in TDD (say 70% of code code is TDD) and I enjoy it.

Sebastian Gozin replied on Sat, 2012/04/21 - 7:09pm

Here we go again.

Joe internet laments how people like Uncle Bob who have written several books and produced many videos of how to practice TDD and explaining why you would do it and why it works ... but somehow that isn't proof enough.

And to top it all of, you assert in a single line sentence that no, these people are foolish and we don't need TDD. You even go so far as to provide some lame alternative like test after... I wonder how you could have worked through any material on TDD and have missed the problems it solves.

Every dev on the planet thinks it's important to have working, clean, malleable and well documented code. I've waited years for someone to teach me a learnable, workable, efficient alternative to TDD and all I've ever gotten is oneliner nonsense like "there are alternatives to TDD".

Are there? where are the books, videos, blogs carefully laying out the techniques and disciplines for doing so? Oh I know where they are. They don't exist and neither do those alternatives to TDD.

Do we have to do TDD? If you want to have working, malleable code with accurate documentation then yes. Does it not matter if the code works predictably or is not documented like with a GUI then no.

And then of course we get some commenter stating the obligatory "TDD is no silver bullet" remark. If you like sayings so much maybe consider the following: "There is no alternative to hard work". Because it sure fees like you're trying to excuse the fact that you're doing a bad job.

Nicolas Bousquet replied on Tue, 2012/04/24 - 3:01pm in response to: Wojciech Kudla

Automated integration/functional testing also provide the same benefit but allow to discover differents bugs. Bug that unit tests can't find because theses are bugs related to integration of several components.

The point is in my team we manage arround 800 bugs a month. It is really unusual to find a bug that could have been covered by a unit test. Most real bugs are due to integration problems that could not have be found by an unit test.

Unit testing is good for new software when you develop something that is dependant of something that isn't available for you to test. In that case, you have no choice.

If other components are already available, integration testing is really interresting. It go less into the detail of the specific new feature (like the algorithm and logic of the feature by itself) but ensure that the new feature interface well with other parts of the system.

Because this is were we experiment most problems, I do found integration testing far more interresting than unit testing for the same amount of time spent on it.

Nicolas Bousquet replied on Tue, 2012/04/24 - 3:24pm in response to: Sebastian Gozin

Sebastian, you make me laugh. All seems to be black and write. But reality is never black or write. Not even a shade of grey. It is full of color. And our eyes can only really see a very small part of theses.

Even if it seems to work for you, even if experimented and recognised people use it with success doesn't mean this is the perfect and ultimate solution that work best for all kind of situation. Other experimented and recognised people don't use it and have success too. Other techniques like code reviews or integration testing tend to offer good return on investmen too, even better in many cases.

Witold Szczerba replied on Wed, 2012/04/25 - 11:27am in response to: Nicolas Bousquet

Does TDD mean nothing but doing unit-tests? When you write integration tests first, isn't it a test-driven approach as well?

For me, TDD means: before doing anything, think first about what is your goal. It is not obvious, but most of the time one can codify the expectations. Those expectations are known as "tests" or "runnable specs". Sometimes they are unit-tests, sometimes they are something else (like an automated application driver or some kind of integration test). Once you have it, once you figured out what you really want, you can focus on implementation. This is what I do understand as TDD.

Nicolas Bousquet replied on Fri, 2012/04/27 - 4:50pm

@Witold Szczerba.

 I agree that the concept is not limited to unit tests. But my impression is that it doesn't scale mutch.

 An integration test that fail for days or months continuously because not all parts already exist might appear less usefull. Test first, imply upfront design. That's nice, at soon as you apply it to small step... Otherwise you are juste doing whaterfall. And that where UT are even more usefull: at the start of a big project with many component. You have to test what you do in isolation anyways as other componens are not yet available.

I'am ok to perform many kind of tests, but I don't like the wishfull thinking we have arround TDD, that is, test first. Well not that, I'am okay with test first, as long as you don't force other or criticise other that test later or mix the too methods. One way may fit better one kind of domain, task or way of thinking. Thinking that everybody has to do everything the same way and that there is not alternate possible solution is not really respectfull... or even likely.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.