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

211–220 of 332 posts

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

#211

Post by 5gtgd5t5e »

blazespin wrote: post #178
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.

Absolutely, this. TDD is hugely valuable especially when new people join the project who don't understand and the best way they contribute is by adding tests!

This is really wrong!

Tests are important, you should not have "the new guy" write them, because they should already have been written, by someone who understood the code being tested. Having some junior dealing with testing is a sure way of producing useless, slow and incorrect tests.

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

#212

Post by yomly »

vacri wrote: post #159
smallnamespace wrote: post #115

Earlier quoted context omitted.

The criticism was very constructive though. Increase the sample size, put it in a more realistic setting.

How do you propose to gather more experienced, professional developers into the same location and get them to work on a topic that isn't making them tons of money? They can't be left to do the problems in their own workplace, or the next criticism will be "uncontrolled variables!". They also have to be vetted for minimum skills (there are plenty of experienced, professional devs out there who aren't worth a second lo…

Whereas the cost of finding the Higgs Boson was only a mere $13.25Bn, cheap compared to all those pesky extortionate SV engineers...

As others have said, good research costs money...

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

#213

Post by richie5um »

donw wrote: post #68

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…

This.

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

#215

Post by shade23 »

jcoffland wrote: post #110
shade23 wrote: post #92

I have spent almost 3 years now writing code(with very few or no tests) and my current organization stresses on agile practices a lot.I encountered TDD from here.So I would like to chip in here too. TDD solved a major problem for me which I have seen a lot of people suffer with. _Where do I start ?_ . The thing is TDD and refactoring go hand in hand. I cannot imagine doing TDD if I was not using an IDE like Intellij…

> When you normally start writing code first(typical TLD) then you need to have a plan before hand. This plan cannot change much because you really do not get feedback till you complete major segments of the code. A good plan is modular and therefore flexible. I get lots of feedback as I'm writing the code. When I find myself writing very similar code over and over or an API feels unwieldy I take that feedback and re…

>I think what really happens in big groups [...] dig in their heels creating technical debt.

This is a major factor. the Pareto principle applies in workplaces too. TDD tries to even the balance a bit.

Regarding feedback.I should have clarified that I am a mobile dev. I need to build everything from the backend services to the UI to be able to get viable feedback without tests. And if any other mobile dev has any other approach to this problem . Please let me know,I've been trying different approaches for a while now. None seem viable to me apart from TDD.

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

#216

Post by Steeeve »

I'm a fan of TDD, but I'm a bigger fan of having reliable, repeatable, and complete tests period.

I don't think it's productive to argue the merits of the study itself - better to look at the positive. What the study tells us is that it's not too late to improve your existing software with tests.

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

#217

Post by _ikke_ »

zorked wrote: post #143
bjelkeman-again wrote: post #132

Earlier quoted context omitted.

> provide no additional benefit over anything else that gets the tests written. Isn't this enough though? The tests gets written, which probably was the main point in the first place?

You can also add a coverage tool to your CI and get the same result (tests get written) without any of the ideology (TDD fairies sprinkle unicorn dust everywhere).

Coverage tools are not sufficient for getting good test coverage. One can easily make code 'covered' without having proper tests for them.

By writing tests early, you make sure the code you are testing is testable and your knowledge about the code is fresh.

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

#218

Post by Shorel »

In a certain way, you always use tests when you are developing something.

Write code, run it, see what happens, repeat.

The 'see what happens' part is what is different in TDD.

It can be very similar to what you do without automated testing (while also repeating all previous tests), or it can be a scaffold on endless tests, or two few tests, or anything in between.

I've seen too many mocking tests for my taste. In fact, my tests tend to be in the 'integration tests, not unit tests' category.

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

#219

Post by vidarh »

zorked wrote: post #143
bjelkeman-again wrote: post #132

Earlier quoted context omitted.

> provide no additional benefit over anything else that gets the tests written. Isn't this enough though? The tests gets written, which probably was the main point in the first place?

You can also add a coverage tool to your CI and get the same result (tests get written) without any of the ideology (TDD fairies sprinkle unicorn dust everywhere).

That assumes you are disciplined enough to act on the result.

Which is what most of these mechanism are about: Finding what causes sufficient friction to get the tests written.

(I'm making this comment because I know of a team with a coverage tool tied into CI where the coverage has been ignored for years)

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

#220

Post by onion2k »

ubu7737 wrote: post #180
onion2k wrote: post #126

Earlier quoted context omitted.

I have a somewhat different experience. I've found TDD is useful on even tiny projects because using TDD forces you to write better code. It's really hard to reliably test things that use "magic" and side effects that affect parts of your code they shouldn't really be affecting, and really easy to test things that have well-defined and properly documented interfaces that only do one thing. Consequently writing tests,…

To me it's sort of like people who use an index card when they read. They move it line-by-line down the page so their eyes have an easier time traversing the line of text. If this is the crutch that makes you a better programmer, who am I to discredit the practice? But dogma has no place in software engineering.

Kind of like those developers who have to rely on syntax highlighting and linters, right? Those guys! :)

Sometimes using something to help you write better code is just a plain old good idea. You can write it off as unnecessary dogma, but if it actually makes your code better you're shooting yourself in the foot a bit.

Post reply on HN