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

61–70 of 332 posts

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

#61

Post by hliyan »

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…

Exactly my experience - I've done TDD for 3 different types of calculation functions in 3 different languages over the years, and all were beneficial: financial risk calculations in C++, report data calculations in PHP and billing calculations in JavaScript.

On the other hand, TDD for operations that involve I/O (including user interactions) were not helpful at all.

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

#62

Post by bbcbasic »

skookum wrote: post #29
ben_jones wrote: post #20

...when implemented poorly

Therein lies the rub with all the faith-based modern development practices. Getting results? That's the power of The Practice. Not getting results or seeing negative impact? You're just not doing The Practice right and/or hard enough.

Cough scrum

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

#63

Post by jpt4 »

dtwhitney wrote: post #50
barbs wrote: post #7

Earlier quoted context omitted.

> if it works for you and your coding style, awesome. But don't force it down my throat or act like it's the One True Path to clean code. This applies to so many things in Software Development - text-editors, variable names, plugins, architectures, operating systems...

nope - vim

Ed.

Edit: ED IS THE STANDARD TEXT EDITOR! [0]

[0] https://www.gnu.org/fun/jokes/ed-msg.html

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

#64

Post by brightball »

candiodari wrote: post #60
brightball wrote: post #19

Earlier quoted context omitted.

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.

It's been very YMMV in mine. For some things, it's indispensable. Others it's tedious, repetitive and of questionable benefit.

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

#65

Post by NumberSix »

Software development varies enormously. Flight avionics software differs from video game software differs from a spreadsheet differs from an order-entry system differs from laboratory analysis software differs from a web browser and so on. Flight avionics differs from a commercial jet liner to a fighter plane to a model airplane. Some projects have huge budgets and others have shoestring budgets. Some projects require extremely high reliability and quality; cost is not an issue. Other projects can be quite buggy, low quality but still useful -- cost effective.

Developers vary as well. Some temperamentally find something like TDD useful. Others do not.

There is no one software development methodology to rule them all.

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

#67

Post by Alex3917 »

geerlingguy wrote: post #5

Could it be that TDD vs. tests-after-code is a highly personal thing? I personally find it easier to write good tests after I've coded something functional. Before hand, I know one or two fuzzy ideas of what I want to accomplish, but I can't list out the concrete, real-world test scenarios until after I've coded something, poked and prodded it, etc. But I know some people are wired differently; they'll think a lot mo…

> I think the chasm exists between _untested_ code and code that has tests.

IMHO untested code isn't always a bad thing. Anything related to privacy, security, or data integrity should be heavily tested.

But beyond that, code should need to earn its tests. (At least in a web startup context.) After all, the core of agility is being able and willing to go in a different direction when something isn't working.

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

#68

Post by donw »

Am I correct in reading that they performed this experiment only for two days, and entirely with graduate students?

If so, they have missed the point of TDD.

In the short term, TDD probably doesn't make a difference, one way or another.

But software as a business is not a short-term game.

I would love to see a study where the participants are, over a period of six months, given the same series of features (including both incremental improvements, as well as major changes in direction).

In my experience, teams that don't test at all quickly get buried in technical debt.

Untested code is nigh impossible to refactor, so nobody ever does, and the end result is usually piles of hacks upon piles of hacks.

As far as testing after development goes, there are three problems that I see regularly:

One, tests just don't get written. I have never seen a TLD (Test Later Development) team that had comprehensive code coverage. If a push to production on Friday at 6pm sounds scary, then your tests (and/or infrastructure) aren't good enough.

Two, tests written after code tend reflect what was implemented, not necessarily what was requested. This might work for open-source projects, where the developers are also the users, but not so much when building, say, software to automate small-scale farm management.

Three, you lose the benefit of tests as a design tool. Code that is hard to test is probably not well-factored, and it is much easer to fix that when writing tests, then it is to change the code.

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

#69

Post by jblow »

haalcion3 wrote: post #42

This is a misleading title and conclusion. The study showed a huge benefit of TDD over Waterfall, and it is only when compared to ITL that it was found to not be better. But moreover, I think it's important to understand why Beck pushed for TDD. TDD is like saying "I'm going to floss before I brush every time, no matter what." But, when people don't do TDD they typically aren't all saying "I'm going to brush and flos…

Waterfall is a straw man.
Post reply on HN