Live data from Hacker News

Test-Driven Development is Stupid

geometrian.com

141–150 of 154 posts

Re: Test-Driven Development is Stupid

#141
The tone of the article is way over the top, but I 100% agree with this quote: "[E]xperience has shown repeatedly that good designs arise only from evolutionary, exploratory interaction between one (or at most a small handful of) exceptionally able designer(s) and an active user population--and that the first try at a big new idea is always wrong."

I agree so much so that the best systems I've built have always been the 2nd revision of a build one to throw it away prototype.

That said, I like to surround my code with lots of unit tests to eliminate absolutely stupid bugs.

Re: Test-Driven Development is Stupid

#142
post #126

Earlier quoted context omitted.

Damn. The misunderstanding just goes on and on. TDD is not a unit testing religion. It's a way of designing software. Some have even advocated calling it Test-Driven Design, not Test-Driven Development, because the end result is a design, not a series of tests. This is important to know, because the key factor in the red-green-blue cycle is the blue step: refactoring. The example given by the author is of a system th…

Daniel, there is no misunderstanding, I know about the two definitions of TDD - one focusing on testing and one on design. I think that automated unit testing is a useful method of reducing errors and regressions, however not alone but as part of a series of quality control strategies such as integration and higher level and manual testing, static and dynamic analysis, using higher level programming concepts, etc. I…

> There's an inherent tension between well designed OO code and testable code.

No, there isn't. Code that is not testable is not well-designed.

> Well designed code is properly encapsulated, does one thing, has a minimal interface and few dependencies.

And testing tests what the consumer of code will use, using the interface.

> Testable code is often less encapsulated, contains extra complexity for the test machinery, among which we can count extra methods (with potentially non-private visibility) and dependencies between classes (such as strategies, policies, factories, etc).

Only if you are doing testing wrong; what you should be testing, even for unit testing, is the behavior of the unit under test as provided through its exposed interfaces to consumers of the unit under test.

> Furthermore, while designing at the class level is important, it is much more important to architect at higher levels: component, subsystem, application, system/platform.

Conventional, unit-test-focused TDD is a practice isolated to a particular level which does not conflict with higher-level practices of the same type that address that concern, like Acceptance Test Driven Development (ATDD).

Re: Test-Driven Development is Stupid

#144
post #8

Earlier quoted context omitted.

This. I agree TDD can cause more harm than good in software design, but my test suite saves me from shipping several regressions per day that I would have otherwise not noticed. Obviously if you are against testing in general you are against TDD (it's just testing taken to the extreme). I thought he at least was going to say that he preferred higher level testing, to low level unit tests (which can be a fair point, y…

How does TDD cause more harm than good in software design?

You quickly get to the situation where the code is clean, concise modular and all those good words, but requires one more tweak/indirection only for the unit testing. the result is popularly called "Test induced design damage".

Re: Test-Driven Development is Stupid

#145

    If you want to change what a function does, you have to change all the tests you wrote for it.
This guy doesn't know how to write good tests at all. The whole point of testing is that you can change those function without any fear of breaking anything because the tests will prove it works the same way as before.

Re: Test-Driven Development is Stupid

#146

Earlier quoted context omitted.

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

Comments are easy to miss though. We arnt perfect about going through our code and testing gives us objective measures.

A test won't say why code is the way it is; it will simply provide some sample input and expected output to that code. This may be enough, but not always.

Re: Test-Driven Development is Stupid

#147

Earlier quoted context omitted.

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

In any other field, specifying a function by its value at a handful of points would be a bad joke. If you don't know what you want your code to do then tests will just make it harder to experiment, and if you do know then there's no harm in writing them after the fact.

> In any other field, specifying a function by its value at a handful of points would be a bad joke.

There is a difference between making the spec explicit (which is providing concrete examples of the spec's meaning) and replacing the spec. You seem to be talking about tests doing the latter, while the grandparent comment talked about the former.

> If you don't know what you want your code to do then tests will just make it harder to experiment, and if you do know then there's no harm in writing them after the fact.

If different people are responsible for the unit under design vs. the parts of the software that will consume that unit, then the concrete examples provided by test cases can help confirm that there is a common understanding of the spec; as such, tests serve to validate the spec.

You want to do that before you code the implementation. And once you've done that, the tests are also available to validate the implementation.

Re: Test-Driven Development is Stupid

#148

Earlier quoted context omitted.

> It continues to amaze me how people go from being a novice to being an expert. One day they can't code at all. Next day they know everything there is to know about it -- and can go on at length about why process X is a terrible thing, without even trying or understanding it. The Dunning-Kruger effect in action.

> The Dunning-Kruger effect in action. But that also applies to ... >> If you see hundreds of really smart people doing X and seemingly very happy with it, there's probably something going on there

That's less Dunning-Kruger and more appeal-to-authority fallacy.

Re: Test-Driven Development is Stupid

#149
post #65

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.

It's not useless, it taught me that weight fluctuates a lot by the hour and some by the week (;

I took the average of the 3-4 last days at the same time (about waking up) is a good enough approximation. Once I learned this, "more often" means once daily, as opposed to "once monthly" (if any). It wasn't only about the hard number, it was about the motivation.

Re: Test-Driven Development is Stupid

#150

Earlier quoted context omitted.

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. The author's point, in the painting comparison and when mentioning other fields, is that you never have a good enough understanding of the problem you are trying to solve when you're just starting to work on it. Developing the code is an i…

And my point is the opposite Developing the tests is an iterative process that refines your understanding of the problem and the correct solution, and only once you've done that do you know enough to write appropriate code.

Maybe it's a matter of personal style. Some people are better if they focus on "how do I write the code that's intended to solve my problem", and some people are better if they focus on "how do I write tests that can determine that my problem is solved, and that the solution is correct."
Post reply on HN