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

91–100 of 154 posts

Re: Test-Driven Development is Stupid

#91

Post by jerf »

TeMPOraL wrote: post #80
zamalek wrote: post #74

There have been one or two HN posts somewhat recently indicate that developers should stop calling themselves "engineers." Enter examples of how engineered solutions generally work the first time round, and how software almost universally does not. There's a fundamental reason for that: it's computer science. One of the facets of science is that you have a hypothesis. Writing a unit test before you start is analogous…

I disagree on multiple levels. First of all, programming is not computer science. Sure, we probably do not deserve to be called "engineers", but what we do goes in completely other direction - away from science and towards art. Secondly, I wouldn't try to fit unit testing into scientific process - because if the test is a hypothesis, then what you're doing is the exact opposite of how science is done. You do not desi…

"Secondly, I wouldn't try to fit unit testing into scientific process - because if the test is a hypothesis, then what you're doing is the exact opposite of how science is done. You do not design your experiment to make your hypothesis come out true!"

True, but I think that objection can be trivially fixed by simply... doing that. I write tests that confirm the code does what I designed, but I also write code that tries to break my design, and tests that verify that it errors as expected. I do approach it with a scientific mindset. (And I tend to consider "scientific mindset" to be the more important part of science vs. some overprivileging some checkpoint list of specific techniques, which ought to have come from the scientific mindset in the first place.)

Of course it remains true that you can't do that perfectly, but that's a null objection in the end. Nothing ever can be, but at least I try.

I can't even count how many times I've tested a code's error case, only to discover that it unexpectedly "worked". Usually that's because there's a bug and I need to fix the error case... every once in a while it turns out my code corrects my own understanding when it reveals what I thought was an error case is actually perfectly valid and sensible, though. It's important to try to break the code.

Re: Test-Driven Development is Stupid

#92

Post by mabbo »

TeMPOraL wrote: post #40
mabbo wrote: post #20

Earlier quoted context omitted.

On the teams I've work on, pushing code that doesn't build and pass all unit tests is grounds for mocking. I have an alias in my zshrc file called "safepush" that runs [clean command] && [build command] && [test command] && git push If any piece doesn't succeed, the command stops. No push without unit tests passing.

And, as the article points out nicely, this basically prevents people from refactoring their code. In any nontrivial codebase, when you have a lot of tests, then what would have been 15 minutes of work rearranging class structure turns into a whole day of rearranging test cases to fit the architecture again.

It can be, I won't entirely disagree. But it depends how highly coupled your unit tests are to the design.

Unit tests are a safety mechanism- you can easily bog yourself down with too many, tying things up in bad ways, or presuming a specific design. But do you really want to live with no safety at all?

The art, as I see it, lies in writing tests in such a way that you get the guarantees you need, the safety of not letting the next guy (or yourself) screw it all up during later changes while simultaneously not preventing you from doing needed refactoring.

It's a fun challenge.

Re: Test-Driven Development is Stupid

#93

Post by ghshephard »

TeMPOraL wrote: post #59
ghshephard wrote: post #22

Just wait until he has to write a system with several hundred web services that have been documented to perform in a very precise manner given particular data sets, and have hundreds of customers who have integrated to that API, and absolutely required that there be no variance in the output in the API, or there (extraordinarily expensive) system integration will fail, at great costs to their business systems. I'm no…

What you described having tests , not doing TDD . That is, it's important to have those test cases verifying that your APIs still work, but that doesn't mean you have to design the APIs by writing tests, as opposed to designing by thinking about what you actually want to achieve.

Fair point. I was more referring to his comment here: I am against writing unit tests in general, since experience shows that they actually prevent high-quality code from emerging from development--a better strategy is to focus on competence and good design.

Re: Test-Driven Development is Stupid

#94

Post by TeMPOraL »

mabbo wrote: post #92
TeMPOraL wrote: post #40

Earlier quoted context omitted.

And, as the article points out nicely, this basically prevents people from refactoring their code. In any nontrivial codebase, when you have a lot of tests, then what would have been 15 minutes of work rearranging class structure turns into a whole day of rearranging test cases to fit the architecture again.

It can be, I won't entirely disagree. But it depends how highly coupled your unit tests are to the design. Unit tests are a safety mechanism- you can easily bog yourself down with too many, tying things up in bad ways, or presuming a specific design. But do you really want to live with no safety at all? The art, as I see it, lies in writing tests in such a way that you get the guarantees you need, the safety of not l…

Exactly what you wrote. That's why I am generally for testing, but I don't buy into Test Driven Development.

Re: Test-Driven Development is Stupid

#95

Post by zamalek »

TeMPOraL wrote: post #80
zamalek wrote: post #74

There have been one or two HN posts somewhat recently indicate that developers should stop calling themselves "engineers." Enter examples of how engineered solutions generally work the first time round, and how software almost universally does not. There's a fundamental reason for that: it's computer science. One of the facets of science is that you have a hypothesis. Writing a unit test before you start is analogous…

I disagree on multiple levels. First of all, programming is not computer science. Sure, we probably do not deserve to be called "engineers", but what we do goes in completely other direction - away from science and towards art. Secondly, I wouldn't try to fit unit testing into scientific process - because if the test is a hypothesis, then what you're doing is the exact opposite of how science is done. You do not desi…

Fair enough.

> art

In stark contrast to what I've said: I also believe this to be true. Software development is a cross section of multiple disciplines: art and mathematics possibly being two of the largest within that cross section. Science, while a smaller component, is still present.

> You do not design your experiment to make your hypothesis come out true!

Indeed, as stated the TDD approach is strange and is only analogous to the formal scientific process.

> driving your design by tests is going a bit too far [...]

I didn't stick to formal TDD for very long for exactly that reason: it takes ages and constrains you to think about the tiny details instead of the grander design of the project. The upshot of formal TDD is that it usually results in low coupling but there are other ways to achieve that.

Re: Test-Driven Development is Stupid

#96

Post by mannykannot »

theseatoms wrote: post #70
hoorayimhelping wrote: post #51

> You are writing code to test something that doesn't even exist yet. I am not rightly able to apprehend the kind of confusion of ideas that could provoke such a method. Yeah, the fact that you can't comprehend why people do this is very clear; if you could, you wouldn't have written this terrible rant. It feels like the author is criticizing this before coming anywhere close to understanding why people do it. I real…

>You are writing code to test something that doesn't even exist yet. To piggyback on this... sure, the code doesn't exist yet, but the project specs do. And unit tests can help by making the required specification explicit.

I agree, but the corollary of that is that if the project specs exist (and they do, at least conceptually), then it is they that are ultimately driving development. This is outside of the scope of TDD, and so TDD is not a complete methodology, a fact that often seems to be forgotten or overlooked.

Re: Test-Driven Development is Stupid

#97

Post by veidr »

mojuba wrote: post #72
ayberkt wrote: post #31

> Let me emphasize: you write the test cases for your program, and then you write your program. You are writing code to test something that doesn't even exist yet. I am not rightly able to apprehend the kind of confusion of ideas that could provoke such a method. I don't understand this. What is so absurd about specifying facts about the program you will write? When we have tools that can prove facts, we will be doin…

Because like the author says, there is no substitute for competence. If you can't write good code, then your assumptions about the future design will be wrong and/or bad, and your tests will be as poorly written. In other words, TDD (anecdotally) doesn't improve your code but only introduces extra levels of complexity. Which in the hands of an incompetent developer becomes an even bigger problem than if there was no…

If you can't write good code, then you will not write good code.

But, there is another common case where unit tests (written before or after) also come in tremendously handy: if you can't write good mistake-free code 100% of the time.

Which describes all programmers who have ever existed.

Re: Test-Driven Development is Stupid

#98

Post by TeMPOraL »

jerf wrote: post #91
TeMPOraL wrote: post #80

Earlier quoted context omitted.

I disagree on multiple levels. First of all, programming is not computer science. Sure, we probably do not deserve to be called "engineers", but what we do goes in completely other direction - away from science and towards art. Secondly, I wouldn't try to fit unit testing into scientific process - because if the test is a hypothesis, then what you're doing is the exact opposite of how science is done. You do not desi…

"Secondly, I wouldn't try to fit unit testing into scientific process - because if the test is a hypothesis, then what you're doing is the exact opposite of how science is done. You do not design your experiment to make your hypothesis come out true!" True, but I think that objection can be trivially fixed by simply... doing that. I write tests that confirm the code does what I designed, but I also write code that tr…

> I do approach it with a scientific mindset. (And I tend to consider "scientific mindset" to be the more important part of science vs. some overprivileging some checkpoint list of specific techniques, which ought to have come from the scientific mindset in the first place.)

True. If you just follow the checklist without following the spirit of the scientific method, you end up doing socio^H^H^H^H^Hcargo-cult science.

As for scientific mindset in programming, I think it's a very valuable thing to have on both larger scale - in various forms of testing - and smaller scale. I found that, when running your code, it's good to just ask yourself what exactly do you expect to happen beforehand, and if you see any deviation, immediately go figure it out, or at least note it down. If a program does something unexpected it means you don't understand it.

Re: Test-Driven Development is Stupid

#99

Post by Freak_NL »

Scarblac wrote: post #77
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...

They are also a word of encouragement to whoever sees your code for the first time because he needs to make a change in it, five years from now. "Look, this code looks strange to you, you would have done it differently, and you are afraid you might break things you don't even know exist. But fear not, there are tests, they run, and they will guide you." It's always relieve to find that some random old crap is actuall…

Not just to someone else. Nothing is more pleasant than going in to refactor code you wrote years ago, and find that you wrote comprehensive unit tests. Thank you past-me!

Re: Test-Driven Development is Stupid

#100

Post by snarfy »

sulami wrote: post #47
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 cer…

I do agree with this, and have felt it from both ends. If you need to change a core class or interface which cascades throughout the system, those unit tests are sure nice to have. I'm not sure I'd be confident enough to change the core class without the unit tests. In that sense, lack of unit tests is momentum against change.
Post reply on HN