31

I know some people are massive proponents of test driven development. I have used unit tests in the past, but only to test operations that can be tested easily or which I believe will quite possibly be correct. Complete or near complete code coverage sounds like it would take a lot of time.

  1. What projects do you use test-driven development for? Do you only use it for projects above a certain size?
  2. Should I be using it or not? Convince me!
Tamara Wijsman
  • 8,259
  • 14
  • 58
  • 94
Casebash
  • 7,662
  • 5
  • 41
  • 62
  • 3
    I have so much trouble just writing tests. Its gotten to the point where I just verify everything manually. – TheLQ Sep 03 '10 at 11:08
  • Have a look at this question: http://stackoverflow.com/questions/301693/why-didnt-unit-testing-work-out-for-your-project – systempuntoout Sep 03 '10 at 18:18
  • 1
    @TheLQ... try telling my customer that my flight-control software is OK because I've done a manual code review :-) – Andrew Sep 23 '12 at 09:40

5 Answers5

32

Ok, some advantages to TDD:

  1. It means you end up with more tests. Everyone likes having tests, but few people like writing them. Building test-writing into your development flow means you end up with more tests.
  2. Writing to a test forces you to think about the testability of your design, and testable design is almost always better design. It's not entirely clear to me why this happens to be the case, but my experience and that of most TDD evangelists seems to bear it out.
  3. Here's a study saying that although TDD takes a bit longer to write, there's a good return on investment because you get higher quality code, and therefore fewer bugs to fix.
  4. It gives you confidence in refactoring. It's a great feeling to be able to change one system without worrying about breaking everything else because it's pretty well covered by unit tests.
  5. You almost never get a repeat bug, since every one you find should get a test before it gets a fix.

You asked to be convinced, so these were benefits. See this question for a more balanced view.

Community
  • 1
Fishtoaster
  • 25,909
  • 15
  • 111
  • 154
  • 10
    "testable design is almost always better design" - I think the main reason for this is because testable code is generally modular and with simplified dependencies. – Skilldrick Sep 20 '10 at 16:46
  • "Everyone likes having tests, but few people like writing them." - is this really true? Seems like it'd be fun to think of good tests, to try to trip up the software being tested. – DarenW Oct 28 '10 at 18:01
  • 3
    @DarenW- I dunno about you, but I'd rather make things work than break them. That said, someone who *does* think the way you suggest is hella-valuable as a tester. There are not enough quality QA guys in the world. – Fishtoaster Oct 28 '10 at 18:18
  • I'm getting a 403 Forbidden error on the lnk to that PDF – Neil N Dec 03 '12 at 17:10
  • Updated to what I'm pretty sure was the same pdf (it was a couple years ago) – Fishtoaster Dec 03 '12 at 19:01
  • I just read the study you linked to at #3 and that's not what the study says at all. In the study the authors propose an economic model to evaluate the ROI of TDD. The authors make NO claims to have used this model on existing data to validate the claim of if TDD really gives a ROI. What this paper does is give you how you could calculate if TDD is worth it economically not if it is. In the results section the results are based upon an hypothetical scenario rather than empirical data. In the conclusion the author say that applying this model on empirical data should be done. – Gilles Dec 03 '12 at 19:54
  • "you end up with more tests" can be a disadvantage. I have seen teams procrastinating on changes because of disruptions to test code -- changes which would normally be easy, without the tests. Better written tests mitigates this problem, but that requires up-front planning and design. – Frank Hileman Jan 17 '14 at 00:56
12

Robert C. Martin originally made these points - I can back them up from my own experience:

  • You will automatically build a regression test suite of unit tests as you go.
  • You will hardly ever spend time debugging, as if you code yourself into a hole, it's easier to undo your code to the point when the last test passed, rather than crack open a debugger.
  • Every few minutes you verify that your code works - all of it (or at least all of the behaviour covered by the tests, which if you're doing TDD is a very high percentage of it).

I pretty much do TDD all of the time, whether I'm working on production or play code; I find it difficult to code any other way these days.

Paddyslacker
  • 11,070
  • 5
  • 55
  • 65
7

(Disclaimer: I do hardly any UI stuff, so I can't discuss TDD for UIs.)

I use TDD in pretty much everything I do, from trivial apps to entire SIP stacks.

I don't use TDD in a legacy PHP website I took over. I find it painful not having tests. And I find it intensely annoying accidentally breaking parts of the site because I don't have a regression test suite telling me I broke something. The client doesn't have the budget for me to (a) write tests for the codebase and (b) in the process make the code testable in the first place, so I just put up with it.

Frank Shearar
  • 16,643
  • 7
  • 48
  • 84
1
  • Whenever your client can be supplied more effectively (they will possibly relate well to tests - and it will at least cut down on end-of-project discussion)
  • Whenever it would take longer keep your co-developers informed on EVERYTYHING in the code than to put effort in building the test - and this is sooner than you may think
Tobiasopdenbrouw
  • 1,001
  • 1
  • 10
  • 10
0

What? No negative answer!?

Disclaimer: I am not anti-unit-testing. When people say TDD, I assume they mean the disease-sounding version where they're writing tests before they write the code for 80-100% of all the code they write.

I would argue:

  • It's an enabler. If catching regression issues is such a huge problem for you that full-auto TDD from the start seems worthwhile, writing tests for every last piece of code you write, might actually help you ignore the real problem.

  • It helps people ignore the real problem. When fixing one bug turns into a game of whack-a-mole where two more pop-up, the architecture blows. Focus. Focus on the real problem. Seeing the moles before they must be whacked is neat-o but you shouldn't be there in the first place.

  • It eats a lot of time. I hit occasional bugs. I do not hit so many that it seems worthwhile to prefix every new thing I write with a test for it. Catch issues where they're likely to happen. Handle errors such that they are easy to diagnose. Validate. Test at key points of overlap/bottleneck. But for crying out loud don't test every last getter and setter in something that probably shouldn't have had those in the first place.

  • Design Focus: There is absolutely no way even a good developer is going to write the best code they could when they are also focusing on the test. If it seems like the only way you can have a decent design, I'd recommend seeing the above about "focusing on the real problem."

  • Macro-Design Fail: The codebase at my current job is riddled with interfaces that never get used more than once and massive violations of basic DRY principle that I only finally started to understand when I realized people were writing for the test-frameworks and testing in general. Testing should not lead to stupid architecture. No really, there is nothing that is somehow more scalable or enterprise-worthy about copying and pasting 20 files and then only making significant changes to two of them. The idea is to separate concerns, not split them down the middle. Cruft and pointless abstraction will cost you more than not have 95% coverage ever will.

  • It's really popular and lots of people really, really like it. If that's not reason enough to at least second-guess and/or vet the crap out of any technology before adoption, learn you some paranoia.

Erik Reppen
  • 6,243
  • 31
  • 34
  • Bah downvoters only read the headline Q and not the contents. – Erik Reppen Aug 08 '13 at 00:32
  • 1
    I downvoted and I read it all. many of the disadvantages you point out are actually addressed by the most basic TDD books. TDD does not mean "just write as many studpi WET un-SOLID tests as you can and never think about design". I think this answer is an unfair misrepresentation of TDD. if your application becomes a mess because people are copypasting and implementing horrible designs, then that is a design issue. TDD is just a workflow, and you are not addressing the workflow. – sara May 02 '16 at 17:49