"I am against writing unit tests in general..."
After this sentence I abandoned the article.
What kind of serious software don't need automated tests? Maybe the kind of no one uses.
Test-Driven Development is Stupid
61–70 of 154 posts
Re: Test-Driven Development is Stupid
#62If you're doing TDD (or software development) like this, you're doing it wrong. Yes, yes, I know. No True Scotsman [1]. But when many - I mean LOTS OF - people say "I get benefits form [Technique]", you can't just say: "It cannot work. I tried it, it sucked.". I mean, you can say that. But doing so makes you look... ignorant - at best. You know, there is a possibility that you just got it wrong. So, many great progra…
>If you're doing TDD (or software development) like this, you're doing it wrong. What do you think is the right way to do it, then?
My point is: If TDD leads you to bad design you're doing it wrong. You are probably not listening to your tests and you are probably not taking care to refactor towards a better design. Maybe you are even writing bad unit tests [1].
BTW, if any technique in software development leads you to bad design, and you don't stop and try to improve something, you're doing software development wrong. If a technique does not help you, you have two possibilities: Trying to do it better (maybe with outside help), or trying something different.
[1] http://www.makinggoodsoftware.com/2012/01/27/the-evil-unit-t...
Re: Test-Driven Development is Stupid
#63Please, correct me if I am wrong, but the process he described is completely against TDD and no wonder it did not work (they wrote the function first, and added tests later, lot of tests, in TDD you would have rather more shorter functions with a few tests for each):
- Function A is 147 lines long. It is the simple core of the program.
- Function A is committed to the repository on June 26th, 2002. Function A has four test cases. Nevertheless, a bug is found in Function A on the 28th and a patch is uploaded on July 6th. It contains two new test cases.
- This continues a bit. However, by August 2002, function A is mostly stable and has no fewer than thirteen test cases--mainly for fencepost errors and other idiotic things anyone can find with a stack trace. Except for a blip in early 2003, function A, now 152 lines long, is unchanged until mid-2006.
Re: Test-Driven Development is Stupid
#64I don't recognise most this criticism. TDD is designing up front. But your designing only a little bit up front. You implement the design, if it doesn't fit, you scrap it and try again. That doesn't matter since its only a little bit.
Re: Test-Driven Development is Stupid
#65I 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.
Re: Test-Driven Development is Stupid
#66There is a way out that he has not found (yet). To design with complete testability as a design goal. TDD with no supporting design can indeed lead to disaster. Hope he can paddle past the rant pond.
Re: Test-Driven Development is Stupid
#67There'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.
That is exactly how I start coding something from scratch, except I don't have that initial test. I don't think such a vague starting test adds anything real.
Re: Test-Driven Development is Stupid
#68>I am against writing unit tests in general, since experience shows that they actually prevent high-quality code from emerging from development
The essay doesn't have the high quality of content I'd expect from PhD candidate in computer science. I'd expect less outbursts of passion and more discussion of pros/cons/tradeoffs.
First, without getting into "TDD" itself, let's just isolate whether "tests" are valuable. I think the examples of SQLite's rock solid reliability (extensive Tcl regression tests[1]) and NASA's disciplined software verification prove that tests help discover bugs and increase code quality.
Tests are valuable -- but they also have a "cost" to write. Let's cover the cost issue at the end.
When to write the tests. If the sequence is: write the code first and then the tests, you might call them regression tests. If you write the tests first and then the code (e.g. iterations to turn red FAILED into green PASSED), you can call it "TDD". And those TDD tests can still function later as regression tests.
To me, TDD acts as a "design" step or "outline" 10,000 foot view. Before any plumbing code is written, what do you want the REST API or group of functions to "look like". Is there unity and coherence to the collection of fucntions modeling the abstraction? The subsequent of fleshing out TDD with "expects()" and "asserts()" is just mechanical work to glue the edit+compile cycles to a verification target but it's not the most interesting aspect philosophically.
However, even though tests have a benefit, there is a cost. The cost-benefit works in some cases but not others:
In my experience, I'm completely sold on TDD (or regression tests) for foundational library type of code. If you're writing a core string library that 100 developers at the company (or open source community) will link into their projects, I prefer seeing extensive regression tests covering all edge cases that proves that it actually works the way the developer intended. It's not strange at all if the code for regression tests outnumber the actual code 10-to-1.
On the other hand, TDD that is mostly UI verification is extremely brittle. If you have TDD that simluates mouse clicks and has "expects()" on reading webpage UI elements to check if things like sales tax calc is correct, you could easily get overwhelmed by all the extra work that synchronizing the actual code and the TDD scenarios generates. (E.g. a UX designer moves an icon 2 pixels or adds a row to table and ends up breaking the entire TDD validation suite for developers.) I could see where TDD at that level would be counterproductive.
Re: Test-Driven Development is Stupid
#69just a sorry rant about how OP tried and failed TDD, and then he points to some project from 2004 that to me seems to be missing code ownership (ppl afraid of changing code they dont fully understand), but to OP seems to be doing TDD wrong.
it's a waste of time to read, as it don't bring anything new to the table. i wish the OP would at least attempt to reflect on what TDD is, what it's not and why oh why, so many devs seems to like it.
Re: Test-Driven Development is Stupid
#70> 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.