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

Test-Driven Development is Stupid

geometrian.com

Post reply on HN
Print view View original

41–50 of 154 posts

Re: Test-Driven Development is Stupid

#41

Post by Diederich »

alanfranz wrote: post #16

There're already people speaking about the limits of a too strict TDD: http://david.heinemeierhansson.com/2014/tdd-is-dead-long-liv... And yes, it may be stupid to test before a design emerges - but only if you start with a very fine-grained test. Usually when I'm coding from scratch I write a very, very, VERY coarse-grained test that "tests something", and when I reach the point of passing it (which may involved cre…

This is my view as well.

More generally, it's about not 'coding too far into the future', even (especially) with tests.

But I like to code a little ways into the future.

'README driven development' is also interesting.

Re: Test-Driven Development is Stupid

#42

Post by mrweasel »

>So this is the first reason TDD fails: You're trying to make a design before you learn anything about it.

Well yes, I use my unit tests to learn what works and what doesn't. You're allowed to rewrite or scrap tests, if they are no longer relevant. In the end I feel that having unit tests result in a better final design.

Yes, sometime unit tests are a little contrived. But they can also help you design cleaner interfaces and increase your code reuse.

Re: Test-Driven Development is Stupid

#43

Post by grhmc »

> I was once one of these newly educated kids. So, for a few years, I worked exclusively with the Test-First strategy. When it was over, the results were undeniable. The code--all of it--was horrible. Class projects, research code, contract programs, indie games, everything I'd written during that time--it was all slow, hard to read, and so buggy I probably should have cried. It passed the tests, but not much else.

Sounds like most everyone's first years :)

Re: Test-Driven Development is Stupid

#44

Post by mabbo »

snarfy wrote: post #18

TDD assumes you know what all the interfaces are going to be beforehand. If you discover that an interface needs to change you have to refactor all of your tests. Unit tests are momentum against change. It also assumes a bug free app with 100% code coverage is the objective, regardless of the cost it takes to write all that test code. An app that has a few bugs but takes half the resources to develop can make better…

> It also assumes a bug free app with 100% code coverage is the objective, regardless of the cost it takes to write all that test code.

I disagree on this. 100% coverage is actually a bad thing, in my opinion, because there's always a lot of code you do not need to test (simple constructors, accessors/mutators, etc).

A unit test should test things that you are relying on being correct. You write a unit test as a way to protect future developers (including yourself) from totally screwing things up by accidentally changing something important.

An application with a few bugs that took half the resources to develop is nice- until the customer needs a few extra changes 18 months later, and you turn 'a few' bugs into 'a whole lot of' bugs.

Re: Test-Driven Development is Stupid

#45

Post by ed_blackburn »

alanfranz wrote: post #16

There're already people speaking about the limits of a too strict TDD: http://david.heinemeierhansson.com/2014/tdd-is-dead-long-liv... And yes, it may be stupid to test before a design emerges - but only if you start with a very fine-grained test. Usually when I'm coding from scratch I write a very, very, VERY coarse-grained test that "tests something", and when I reach the point of passing it (which may involved cre…

>Usually when I'm coding from scratch I write a very, very, VERY coarse-grained test that "tests something", and when I reach the point of passing it (which may involved creating and designing multiple classes) I probably have a working design and I may begin creating other, smaller unit tests for individual components. The initial test may disappear or become an integration or acceptance test.

This reads pretty much how I work too.I don't think it is unusual. Start coarse, outside in. Write the finer grained 'unit' tests where appropriate. Focus on where you need the crutch (design and confidence) not on clambering to test all the things.

Re: Test-Driven Development is Stupid

#46

Post by falcolas »

tomp wrote: post #19
henrik_w wrote: post #4

A while back I described the benefits I think unit tests give you: 1. Well-tested parts 2. Decoupled design 3. Rapid feedback 4. Local context to test in. At the same time, there are many cases where they don't help much. More here: http://henrikwarne.com/2014/09/04/a-response-to-why-most-uni...

I think you're missing the most important one: ensuring you don't unexpectedly break your own code in the future (when you come back in 6 months and forget why exactly it's arr[1:n-1] not arr[0:n-1] or arr[1:n]).

Sounds like a well placed comment would be of more value than a test there.

Re: Test-Driven Development is Stupid

#47

Post by sulami »

snarfy wrote: post #18

TDD assumes you know what all the interfaces are going to be beforehand. If you discover that an interface needs to change you have to refactor all of your tests. Unit tests are momentum against change. It also assumes a bug free app with 100% code coverage is the objective, regardless of the cost it takes to write all that test code. An app that has a few bugs but takes half the resources to develop can make better…

> Unit tests are momentum against change.

I get the point, but feel different. When a project becomes large enough, changes can result in breakage in the weirdest places. Proper testing can help discovering this breakage before shipping. For me, tests are a safety net for changes in the tested code.

Large projects without any tests are effectively unmaintainable, often times even for the original author, and most certainly for others.

Re: Test-Driven Development is Stupid

#48

Post by zaargy »

Oh look another article with a provocative (e.g. link-bait) title. I'm sure this will be a well-balanced, nuanced piece on the costs and benefits of TDD, when it makes sense, when it does not make sense, and will leave me with a better understanding of the subject.

Oh.

Re: Test-Driven Development is Stupid

#49

Post by TeMPOraL »

zeveb wrote: post #37
mabbo wrote: post #6

> I am against writing unit tests in general, since experience shows that they actually prevent high-quality code from emerging from development And he's lost me in his first sentence. Unit testing, good unit testing at least, is not just about developing as it is about preventing regressions. A unit test that runs on every build ensure that something is true and that it stays true forever.

I think I see part of his point, though. By its nature, a unit test is (often, albeit not necessarily) tightly coupled with the thing it is testing--which means that anyone who changes the implementation must change the test, which increases the complexity of code changes. I know that in my own work, the single most important thing for me is to be able to massively refactor, restructure and redesign my and others' co…

Regression tests are absolutely awesome, especially if written for nontrivial components which will later be modified or expanded.

Having worked with dynamic languages quite a bit, I found that iff your language has a decent REPL, so you can code iteratively, you don't need unit tests to drive your design. You perform those tests in REPL yourself, which helps you flesh out the design, but you don't have layers of code that'll make changing the design harder.

The way I personally work with Lisp is a mix of writing code in a file, compiling particular parts of it and playing around with it in REPL until I've figured out the right design - at which point I may as well start adding some tests around tricky places. The idea is to not burden yourself with permanent tests until you have your design figured out.

Post reply on HN