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

71–80 of 154 posts

Re: Test-Driven Development is Stupid

#71

Post by rafadc »

> 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.

False dilemma. Are competence and good design exclusively from people that don't TDD?

> The basic idea--amazingly, one of the most popular methods of software engineering (and growing in popularity!)--is that, after you figure out what you want to do and how you want to do it, you write up a set of small test programs--each testing some tiny piece of the program that will exist. Then, you write the program.

No. You are wrong. It is not that.

> 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.

You are writing specifications for a program that doesn't exist yet!? Nuts.

> The most important argument is a practical one: Test-First doesn't work.

It doesn't work because it doesn't work. Sad argument.

> 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.

So it didn't work for you so it is everybody else's problem but yours.

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

No. You are not. Indeed, depending on how you decide to do your tests you should be able to change your design and the underlying implementation and no test should break. Please, take a look to the outside in approach.

> Week 3-4: Write tests.

> Week 5-10: Write code.

Oh my god. This is terrible. And no, this is not TDD either. This is inverse waterfall :P

> Even if you somehow succeed, TDD prevents incremental drafts by functionally requiring all tests for a module to pass before you get any real results.

Probably this is a misconception too. You don't write all the tests before. One test, small implementation pass, another test, small implementation pass... You get the results incrementally.

> There is literally no substitute for competence. If your coders don't have it, TDD won't fix it.

I fully agree on this. And probably this is a really common misconception. But false dilemma again. I don't think TDD came in this world to turn bad programmers into good programmers. It is just another tool in the toolset. You can have terrible programmers that do TDD and excellent programmers that do it.

My recommendation: https://vimeo.com/68375232

Re: Test-Driven Development is Stupid

#72

Post by mojuba »

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 TDD.

Re: Test-Driven Development is Stupid

#73

Post by TeMPOraL »

tdkl wrote: post #65
franciscop wrote: post #11

I love the first quote for how (ironically) true it is: "Trying to improve software quality by increasing the amount of testing is like try[ing] to lose weight by weighing yourself more often." From someone who has lost over 15kg in the past in few months, one of the things that helped most was starting weighing myself as I didn't do that previously. It kept reminding me that I wasn't still there and gave me more mot…

What is "more often" ? Weighing yourself daily is useless, since the weight fluctuates too much. Not to mention that "weight" is useless as well, while you're actually trying to loose FAT. Fat percentage and resulting lean body mass (body weight minus body fat) are the metrics to measure. But still a waste of time doing it daily, twice per week to gain insight on the delta and where it's trending is enough.

Weighing yourself daily is not useless. The idea of doing it weekly is being spread explicitly because GenPop doesn't understand the concepts of a moving average and a low-pass filter - instead, they freak out over those daily fluctuations. If you weigh yourself daily and remember to always look at the average of the last few samples, you get a more useful indicator of your current weight trend.

Re: Test-Driven Development is Stupid

#74

Post by zamalek »

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 to having the hypothesis: "the solution I come up with for this problem will work." The rest of the exercise of TDD is a scientific process of creating a solution and proving that your solution works (and adjusting your hypothesis if you find it to be incorrect), albeit in a slightly strange way.

I could have a hypothesis about how earth is really traveling through the stars on the back of a turtle. We know that is not true because Einstein came up with a solution, followed by him and others proving that solution. Relatively is only valuable because proof of it exists.

If computer science is a science (which it is) we must put our solutions to the same degree of rigor that other scientists do.

While I no longer follow the strictest form of TDD (starting with tests that fail to compile) I'll never forget the singular most important lesson that it has taught me:

    A solution is worthless if you cannot prove that it works.
I'd take this article more seriously if Mr. Mallett provided an alternative for correctness proofing. I can't honestly sell software to someone if I don't know if it works myself.

Re: Test-Driven Development is Stupid

#75

Post by Freak_NL »

reasonality wrote: post #9
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.

It depends what you're developing, and who you're developing with. If you're developing something which must work 100% every time or else someone will die, then unit tests are a must. If you're developing with people who break the build all the time, then unit tests are useful. Unit tests that aren't 100% up to date with the code are worse than no unit tests.

In any halfway decent build your tests will run whenever you build the project, to prevent tests from ever getting outdated.

If any test fails, it is because you broke it just now, so you go in and see if your test is broken, or, as is often the case, your refactored code is breaking the expected behaviour of the tested code.

Re: Test-Driven Development is Stupid

#76

Post by bguthrie »

I'm not clear what technique this article is trying to describe, but anyone that spends two weeks pre-writing tests is not performing TDD. That simply isn't how it works.

The cycle is: red, green, refactor, repeat. That's per test. It shouldn't take long. It works nicely.

Re: Test-Driven Development is Stupid

#77

Post by Scarblac »

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 actually well tested.

Re: Test-Driven Development is Stupid

#78

Post by drumdance »

tdkl wrote: post #65
franciscop wrote: post #11

I love the first quote for how (ironically) true it is: "Trying to improve software quality by increasing the amount of testing is like try[ing] to lose weight by weighing yourself more often." From someone who has lost over 15kg in the past in few months, one of the things that helped most was starting weighing myself as I didn't do that previously. It kept reminding me that I wasn't still there and gave me more mot…

What is "more often" ? Weighing yourself daily is useless, since the weight fluctuates too much. Not to mention that "weight" is useless as well, while you're actually trying to loose FAT. Fat percentage and resulting lean body mass (body weight minus body fat) are the metrics to measure. But still a waste of time doing it daily, twice per week to gain insight on the delta and where it's trending is enough.

I do it daily as a motivation trick.

Re: Test-Driven Development is Stupid

#79

Post by snowwolf »

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.

Anecdotal, but I've always found that if you can't write the test first it's a good indication that you probably don't yet have a good enough understanding of the problem you are trying to solve.

Regarding the rest of the article it is pure trolling with nothing really useful to add to the debate.

Re: Test-Driven Development is Stupid

#80

Post by TeMPOraL »

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 design your experiment to make your hypothesis come out true!

While the quote you cited is interesting, I'd treat it with a grain of salt, given that you can't prove that your solution works - and if you think you did, it usually turns out the proof itself is wrong. It happened even for formally proven algorithms.

Testing gives you increased confidence. It's a worthwhile goal. But IMO, driving your design by tests is going a bit too far, and something you don't need to do to have tests that ensure your code works.

Post reply on HN