Giving Up on TDD

Post by vorg » Sat, Mar 19, 2016, 10:50 PM UTC

EdSharkey wrote: post #20

legulere wrote: post #2

> but he said he was just using it for some home projects I think here lies the biggest problem. For small/hackish projects you barely get any benefits from test driven development but still have the higher costs. Test-driven development means that you will spend more effort while developing, but will have to spend less on maintaining in the long run. The fun part about home projects is that you don't really have to…

My home projects become tragic when they get past the trival size and I haven't been TDD'ing and designing all the way through. I think part of my problem is that I cannot devote a consistent level of effort every week to my current home project. Sometimes I'll leave and when I come back to it, I'm lost without a test suite and wind up rewriting huge swaths of it. Really good tests also serve as up-to-date documentat…

  def "adder-test"() {
    given: "a new Adder class is created"
    def adder = new Adder();

    expect: "Adding two numbers to return the sum"
    adder.add(3, 4) == 7
  }

Post by ryanbrunner » Sun, Mar 20, 2016, 12:07 AM UTC

aikah wrote: post #78

ryanbrunner wrote: post #6

There's definitely some good points here, but I have a huge issue with this point: > Something that is hard to test is badly designed. In my experience, TDD has a natural tendency to favour decoupling at all costs, and TDD zealots will push de-coupling units as an unqualified positive. And if your metric is "good design = easily testable and low coupling" it certainly looks that way. This mindset fails to take into c…

> In my experience, TDD has a natural tendency to favour decoupling at all costs, and TDD zealots will push de-coupling units as an unqualified positive. And if your metric is "good design = easily testable and low coupling" it certainly looks that way. Depends on the kind of TDD. I feel like TDD as Unit Testing driven design IS a waste of time (I'm talking about unit tests first here). However integration testing fi…

Post by Silhouette » Sun, Mar 20, 2016, 12:46 AM UTC

erichmond wrote: post #44

aalvarado wrote: post #13

Earlier quoted context omitted.

TDD is better than no tests most of the time I think. So at least that's a gain altogether.

It should be noted that TDD specifically means writing tests before you write application code. For example, at our shop, we don't require devs to do TDD, however we require test coverage. I don't think anyone would argue that writing tests at all is a bad idea, I think the debate is whether or not your tests should drive your application code.

Post by jacques_chester » Sun, Mar 20, 2016, 1:18 AM UTC

Silhouette wrote: post #82

jacques_chester wrote: post #22

Earlier quoted context omitted.

> Because the benefits aren't higher, in fact they are lower It depends on what you think the benefits are. > As usual my advice on this is: look at the people who build things you find highly impressive, and study how they did it. Good idea. Researchers at Microsoft and IBM conducted studies of applying TDD to real, commercial projects of varying sizes, languages, team structure and complexity. They found that defec…

The Nagappan study is one of the few that at least tried to do a decent job, but there ought to be some sort of magic auto-responder every time someone cites it that points out that none of the teams they studied was actually doing "pure TDD" as originally advocated by those who coined the term, so the baseline for all those comparative figures isn't entirely clear. It's also pertinent that it always seems to be that…

Post by Silhouette » Sun, Mar 20, 2016, 2:01 AM UTC

jacques_chester wrote: post #87

Silhouette wrote: post #82

Earlier quoted context omitted.

The Nagappan study is one of the few that at least tried to do a decent job, but there ought to be some sort of magic auto-responder every time someone cites it that points out that none of the teams they studied was actually doing "pure TDD" as originally advocated by those who coined the term, so the baseline for all those comparative figures isn't entirely clear. It's also pertinent that it always seems to be that…

> none of the teams they studied was actually doing "pure TDD" And still showed dramatic improvements in defect prevention. > surely after all this time we should have a vast body of evidence where real world development teams have tried it and found it clearly superior to what they were doing before, not just a few isolated examples. The problem is funding. Nobody wants to stump up their project for it. Oh, except a…