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.
|
(I mark this answer community wiki - welcome to contribute.) |
||||
|
|
|
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. |
|||||
|
|
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 |
|||||
|
|
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). |
|||
|
|
|
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
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:
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 |
|||
|
|
|
here is a good one |
|||
|
|
|
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) |
|||
|
|