Tell me more ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

At my company I am trying to make a case for why we should be doing TDD. Currently most developers just do whatever they can to get the project done, then go add unit tests after the fact in order to meet manager metrics. Any examples from reputable companies doing TDD and seeing the benefits would be greatly appreciated.

share|improve this question
1  
Actually I think "add unit tests, and hope their manager doesn't notice them 'wasting time'" is more common than "add unit tests in order to meet manager metrics", but I guess that's why some case studies would be nice. – Carson63000 May 7 '11 at 22:24
1  
Also TDD allows you to very early in the process define when you are done as you have all the tests that must pass. – user1249 May 8 '11 at 13:45

7 Answers

up vote 4 down vote accepted

(I mark this answer community wiki - welcome to contribute.)

share|improve this answer

There is a chapter about TDD with a case study in the recent book, "Making Software: What works and why we believe it". But you may be disappointed, since if I recall correctly the study did not uncover any real benefits to TDD. The case study was interesting anyway, and the book in general is one of the best software books I'v read recently. It contains many case studies of things like pair programming, code review, etc.

share|improve this answer
I should be clear that TDD is defined as write tests first (that fail) and only then write code. This is compared against the approach of writing src code and then writing tests. Obviously if you don't write ANY tests at all you're an idiot. Everyone should write tests. TDD just takes issue with when exactly you should write them. – Kevin May 7 '11 at 22:02
+1 for this book. Excellent stuff. – Kyle Hodgson Dec 17 '11 at 20:19

look at how much time you and the client spent manually testing the software; compare that to an estimate of how long TDD-style automated tests would have taken. Pocket the difference

in my experience, TDD's automated tests are gold because they provide insurance and eliminate enormous amounts of manual testing

share|improve this answer
1  
I agree, but it's also important to note that passing the unit tests does not mean that the software is correct, only that it does what the unit tests except. If the unit test is buggy then the software might have a bug, too. If it doesn't pass, the software might even be correct, if the unit test is buggy. This is why manual testing is also needed. – fish May 8 '11 at 13:45

you want to make the case for it: suggest you do it for the next project, and then learn from it. If it turns out it works great for you, then I hope you'll continue to use it and if it took longer to do the project and/or spend all your time writing tests instead of coding, then you'll surely dump it as a failure.

I think the real-world solution is (like most things) a mid-way, you want tests but you don't want the tests to be more important than the project.

(personally I think TDD is a fad, sounds good in theory, but in practice... not so good. I find integration testing is far more important, but that could be just the kind of complex projects I work on).

share|improve this answer

I have been working using TDD for 2 years and where I worked at the time ,we were all reluctant to use including managers.However it soon turned to be the right thing todo.The benefits that we soon noticed were

  • Discovering bugs at an early stage.
  • Writing Better code without even realising.
  • Your code is now more maintainable as due to your testing is all in small chunks (we hadfunctions that were 300-400lines)silly. Now max 30 and all indenpendently tested.

The managers would not know as they are all interested in one thing "Have you finished". But then they complain when the software keeps breaking without realising. With a good coverage and sensible tests.It's not the quantity but quality you can really see when somebody breaks a functionality. Also unfortunately it's difficult if you are on your own.I had the same problem,as you might need to change code eg base classes etc so that you can make parts of the software testable.

I give you an example.I wanted to mock the repository but there was no interface and i need to inject the repository into my service layer and therefore add/modify a constructor all over the shop,this turned out to be a big deal but in the end i have more than 200 tests just testing one area of the system and they were impressed.

I usually do the following:

  • I keep my unittests very short
  • Only 1 assert .No russian roulette.
  • I test a positive -negative and exception scenario

Regarding case studies I am afraid ,I am not sure I have seen any. You need to build your project and become your case studies.They might be impressed too.

I hope it helps

share|improve this answer

a bit late, definitely check out this: http://theruntime.com/blogs/jacob/archive/2008/01/22/tdd-proven-effective-or-is-it.aspx. The author has a lot of good points about TDD not being all that effective (imo despite being hyped to death)

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.