An External Replication on the Effects of Test-driven Development [pdf]

Post by crdoconnor » Wed, Oct 19, 2016, 3:12 PM UTC

piaste wrote: post #307

crdoconnor wrote: post #237

Earlier quoted context omitted.

>You can have tests without TDD ? I've worked on several projects without this and the tests done without TDD tend to be of higher quality. I noticed a common anti-pattern of "write the code, run the code, copy the output of the code, paste it into a test and write an assert to check that the output was precisely what came out". This was brittle, it killed the self-documenting aspect of the tests and it often conceal…

> I've worked on several projects without this and the tests done without TDD tend to be of higher quality. Do you mean "with TDD", by any chance? The rest of your post says that you observed better results when tests were written before the code (rather than later). But as far as I understand, writing the tests before the code is indeed one of TDD's commandments.

Post by platz » Wed, Oct 19, 2016, 3:44 PM UTC

ivan_gammel wrote: post #286

spatulon wrote: post #278

Earlier quoted context omitted.

This benefit of test-driven design is not obvious (at least it wasn't for me) until you really experience it. Several years back I wasn't aware of the concept of dependency injection, but independently discovered it while trying to unit test some error logging functionality. Previously I'd always used a global/singleton logger object. That always felt wrong, but I always assumed it was necessary until writing unit te…

Well, I practiced TDD for no less than 10 years, and its benefits are still not obvious, more like something that needs to be continuously reviewed in the context of the current work. Once you've understood all the design patterns that TDD enforces, you don't need TDD to use them. You just think how you _would_ test your code and defer test implementation for future.

Post by mempko » Wed, Oct 19, 2016, 3:55 PM UTC

mseebach wrote: post #108

jdlshore wrote: post #71

This study, like most software development studies I've seen, is seriously flawed. It doesn't justify the sensational title here on HN. * The sample size was tiny. (20 students) * The participants were selected by convenience. (They were students in the researcher's class.) * The majority of participants had no professional experience. (Six students had prior professional experience. Only three had more than two year…

From experience, the value of TDD (or any style of automated tests, really, you don't really have to be driven by them) only really kicks in when the code is of a certain size, complexity and age. They are much closer to a tax in the early phases when you can reasonably keep the full scope readily in your mind.

Post by kyberias » Wed, Oct 19, 2016, 4:05 PM UTC

mempko wrote: post #315

mseebach wrote: post #108

Earlier quoted context omitted.

From experience, the value of TDD (or any style of automated tests, really, you don't really have to be driven by them) only really kicks in when the code is of a certain size, complexity and age. They are much closer to a tax in the early phases when you can reasonably keep the full scope readily in your mind.

I would say the cost of TDD only kicks in at scale... unit tests are a real cost that plague a project and make devs ultra conservative.

Post by Beltiras » Wed, Oct 19, 2016, 4:35 PM UTC

drostie wrote: post #314

Beltiras wrote: post #272

Earlier quoted context omitted.

If you could bang a car against a guard rail without incurring the cost of a car, you would.

I mean, you do incur a cost for programming with TDD though. The benefits may repay the cost in the end, but the cost is still there. And for that matter cars do undergo destructive testing, just not TDD--and the problem there is presumably that the car benefits from taking a holistic component-driven approach, "here is what I want the car overall to look like, and what components I want to fit into the space inside,…