Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

people.brunel.ac.uk

Post reply on HN
Print view View original

51–60 of 332 posts

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

#51

Post by err4nt »

tspike wrote: post #14

My experience has been that TDD is worthwhile when working with notoriously slippery whack-a-mole functions like handling time or money. The time saved by catching regressions vastly outweighs the time taken to implement the tests. In contrast, TDD has been a waste of time for me for UI-based work, as the effort needed to properly expose the functionality under test is too great and the requirements and design change…

Can you elaborate more? Im a frontend guy and sometimes I write JS plugins for the browser (that run after page load, and apply based on how things render on the page, or bawed on user interaction with the page) and non-frontend folks tell me I need tests for my code, or dont want to look at it until I have test. How would I build a tewt for this, other than a functional test that runs in-browser and the test is whether it works or not?

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

#52

Post by lowbloodsugar »

"TDD has little or no impact on development time or code quality when compared to the equivalent number of tests implemented afterwards using TLD."

FTA: In this paper we reported a replication of an experiment in which TDD was compared to a test-last approach.

Very different title.

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

#54

Post by zzalpha »

wpietri wrote: post #47
problems wrote: post #8

Earlier quoted context omitted.

If you write testable software and actually write the tests, the end result is the same whether you test first or test later. You're designing with testing in mind and creating useful tests either way. It's really a matter of code that lacks tests that's an issue and especially of code which isn't designed with testing in mind. I think they overinterpreted the value of TDD as simply test-first. Test first can be good…

> If you write testable software and actually write the tests, the end result is the same whether you test first or test later. This is definitely not my experience. As Kent Beck says, TDD is a design technique. It forces you to always start thinking of the code from the outside of the unit. If I build the unit first and add tests later, it's more likely I'll end up with something where the API reflects the implement…

If I build the unit first and add tests later, it's more likely I'll end up with something where the API reflects the implementation. With test last, I'm also less likely to test everything well; after the implementation is done, I believe it works.

Will you?

Are you sure?

Do you have data to back your supposition?

My contention would be that at the end of the day, the requirements of the interface to support unit testing will result in a very similar set of design choices, whether you write those tests up-front, as-you-go, or after-the-fact.

The only difference is that if you write them after-the-fact, you may push some amount of refactoring to the end of the process instead of doing it along the way.

But I'll bet you have about as much data as I do to back your beliefs. ;)

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

#55

Post by DannyBee »

jmadsen wrote: post #40
sporkenfang wrote: post #39

Earlier quoted context omitted.

You clearly think very highly of CS grad students :) I've met a few that couldn't code let alone write proper tests, even though their foci were not policy or say the lighter side of user experience.

Really? Almost all of the post-graduate CS students I've known are experienced people who went back to school because they were at the point where they needed to either move into management or become a very high-level expert. That's only personal experience, however, and mostly out-of-date That said, I would hope any of them would be a step up on the new programmers from the "churn 'em out" short courses many are for…

Yes. I can say 100% that the major difference I see in hiring interviews between grads and laterals is coding ability. Even at PhD+1 it's vastly improved

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

#57

Post by danjoc »

zzalpha wrote: post #36
danjoc wrote: post #34

Earlier quoted context omitted.

And yet, that is not what the clickbait title implies.

Only if you think unit testing necessarily requires TDD (which is defined as writing tests before writing the code that passes those tests). It doesn't. All the article says is TDD has little or not impact... it does not say unit testing as a practice has no impact. Seems to be a common misunderstanding around here that you, too, have fallen victim to...

>Seems to be a common misunderstanding around here that you, too, have fallen victim to...

I work with people who openly believe that unit testing is a waste of time. Personally, I think they are afraid, because they don't even know how, and don't care to learn. They would see that title, and that's all the confirmation bias they would need.

Thanks for assuming the worst about me though.

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

#58

Post by nostrebored »

inglor wrote: post #28

There is a problem with all these studies - they all use a very small amount of programmers (21 in this case) with no experience (all graduate students in this case) and presumably no significant experience with TDD or TLD. I'm not making a stand about TDD here - I just think we need to have much better computer engineering science studies if we want to have significant results.

Really don't know why you're being downvoted. Grad students at diploma mills are awful programmers, and even those in real labs are good at putting out proof of concepts, not production code.

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

#59

Post by supersan »

Up until now it has mostly been opinions and biases and even though many popular programmers[1] have been saying this for a very long time, it's great to see a controlled study done about it.

This makes it a fact and a great counter argument for helping a lot of programmers who are being forced to practice TDD because of the generally accepted claims in productivity and code quality associated with doing it.

[1] http://david.heinemeierhansson.com/2014/tdd-is-dead-long-liv...

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

#60

Post by candiodari »

brightball wrote: post #19
tspike wrote: post #14

My experience has been that TDD is worthwhile when working with notoriously slippery whack-a-mole functions like handling time or money. The time saved by catching regressions vastly outweighs the time taken to implement the tests. In contrast, TDD has been a waste of time for me for UI-based work, as the effort needed to properly expose the functionality under test is too great and the requirements and design change…

Agree here. Tests the stuff that needs testing.

That means you can't use coverage tools, so this approach makes the tests unquantifiable. It is not how most major dev shops work, because of the bean counters and the "senior" developers/leads/managers/... who seem to want nothing but appeasing beancounters.

It also produces superior software in my experience.

Post reply on HN