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

91–100 of 332 posts

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

#91

Post by paulddraper »

embwbam wrote: post #88
paulddraper wrote: post #85

Earlier quoted context omitted.

TDD vs. test-after-code is a small distinction. 80% of software development is designing correct abstractions/interfaces/APIs. If you have the correct abstractions, everything else is easy by comparison. And both tests and code are fundamentally founded on these early design decisions. So whether I do TDD or tests-after-code, I'm confronted with the 80% first: designing the interfaces (either in writing or mentally).…

This is why designing the interface in a language with a powerful type system provides the same quoted benefit of TDD. It helps you think about the interface before you move to implementation. In my experience, using a type system to do this requires much less effort and refactoring.

I am a big fan of "testing via types".

Unit tests can demonstrate that my code is correct; it can say nothing about how my code is used by others.

In contrast, a type system can extend those protections downstream.

(Yes, yes, unless you go way off the deep end of dependent types, you still need tests. But a powerful type system can systemically prevent a huge number of very common bugs.)

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

#92

Post by shade23 »

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 or something. 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. TDD ensures you keep getting nibble sized feedbacks which assure you that what you are writing works. This according to me is the single most beneficial point of the system. TDD or TLD would allow maintainable code too.And often while doing TDD too,you can strictly follow TDD. It might not have an impact on code quality for seasoned developers(coding for years on the same codebase) but it does help for the others .It also reduces my inertia considerably too. So while it might not have impacts on development time or code quality. I tend to sleep well without large UML Diagrams floating in my head and knowing that each unit of my code works independently.

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

#93

Post by madeofpalk »

shubhamjain wrote: post #86
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…

> But don't force it down my throat or act like it's the One True Path to clean code. When I was a programming beginner and started learning about TDD, I was always thinking how soon to start using it because everyone says it's such a good idea. If you would search anything about it, you'd rarely find a resource not marvelling at its surprising benefits (at least, that is how it was few years back). Granted, it may h…

Reminds me of a comment by Harry Roberts on CSS methodologies https://twitter.com/csswizardry/status/539726989159301121

    Modularity, DRY, SRP, etc. is never a goal, *it’s a trait*.
    [...] understand that they’re approaches and not achievements.

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

#94

Post by pvg »

refulgentis wrote: post #9

My anecdata matches the author's - I feel more productive doing TDD. Perhaps because it's less stressful. You think about system design as you code, instead of only when you hit a wall and have to rewrite everything, or when you have to clean up for code review. Either way, if it has little to no compact on dev team or code quality, I bet the positive impact TDD has on team morale would make it worthwhile.

Extrapolating from that, perhaps it's worth considering the benefits of thinking about system design before you code.

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

#95

Post by namuol »

- Population: A classroom of students, most without professional experience

- Sample size: 21 students

- Study duration: 2 days

- Team size: Individual

Tests are most useful when refactoring someone else's long-forgotten code; the sort of thing that happens frequently in long-running projects consisting of large teams. In other words, the "real world".

Show me that study.

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

#96

Post by Rapzid »

danjoc wrote: post #57
zzalpha wrote: post #36

Earlier quoted context omitted.

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.

Unit testing is not always a waste of time.

Unit testing can be a waste of time.

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

#97

Post by arcticbull »

I've tried to TDD numerous times in my professional career; I'm confident it works for many. I prefer to use white-box as my second pass through at my algorithm. It allows me to identify potential weaknesses, write test cases around them and correct them in one step. I never feel quite as secure with TDD as I do with post-hoc testing. I'm also not going to tell other people that's the one-true-path. Unit tests? Critical. Before vs. after? Personal.

With respect to this study, I think at best we can say that equal quality tests yield equal results. I don't think -- based on reviewing the methodology -- that the headline can clearly be drawn from the study.

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

#98

Post by hackuser »

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…

It may be unfair to say this in response to the parent comment, but the great majority of HN discussions start with a comment like this one: It's seriously flawed, etc. Occasionally it's true, but the noise drowns out the signal.

In a graduate-level engineering class, the students were making similar statements about all the studies we read. One day the professor said: It's easy to find flaws in someone else's work; humans are flawed. The real challenge and benefit is to find the value in their work - find what has lasting value, learn from it, and carry it forward.

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

#99

Post by jcoffland »

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…

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

The mistake is in creating unrefactorable code. TDD may be a possible solution if done correctly but there are other ways to skin that cat.

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

#100

Post by EdSharkey »

The

  * fire your QA team

  * dev team is the level 2 production support, and

  * get to continuous integration nirvana
management fads have been sweeping through my Scrum enterprise for the last 18 months.

Teams that aren't testing constantly, well, they've got tons of escape defects on every release. And those devs are constantly in fire-fighting mode, it's miserable for them. And I see that leading to compressed schedules for them and more reckless behavior like asking to push their releases during the holidays where there could be severe financial consequences to bugs.

As far as I'm concerned, in an environment like mine, where developers can no longer hide their incompetence behind bureaucracy like a QA team, it is official insanity to not spend inordinate amounts of development time writing automated tests. You should be spending 70% of your dev time writing tests and doing devops and 30% writing features.

I read in these comments a lot of bellyaching about how much time it takes to write tests. First, TDD is a skill that you can get good at, and it won't take as much time as you think once you get good. Second, I just don't think you have a choice to not test comprehensively when escape defects become a mark of shame in the organization.

Post reply on HN