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

TDD is dead. Long live testing.

david.heinemeierhansson.com

Post reply on HN
Print view View original

71–80 of 166 posts

Re: TDD is dead. Long live testing.

#71

Post by enginerd »

I've often found ideals don't quite translate into practical application. Within economics, political theory, etc., I think TDD also deserves a place as a 'wonderful ideal' that fails simply because it does not take into account it's implementing process: human action. Not to mention that the way many programmers learn and code today seems at odds with the structured nature of creating tests.

Maybe there is a better approach to writing maintainable code than TDD? I imagine a world where all code is understandable, readable, and instantly recognizable, but once again we arrive at the fork where the 'ideal world' deviates from the real one in which we all reside. Shame.

Re: TDD is dead. Long live testing.

#72

Post by TimPC »

My biggest problem with TDD is that it tends to take people away from whiteboarding and thinking about architecture and into writing everything as if it were a recursive problem -- write test for base case, code base case, write test for next base case, code next base case, write some significant test case, code general case but often this is completely the wrong pattern for solving a problem. This may be an example of doing it wrong, but it seems to be the practice experts promote when using TDD on a problem (it's very common in both blogging and books).

There are great blog posts of this including Dave Thomas getting horrendously bogged down in writing a Sudoku solver in a situation that could be well handled by going to a whiteboard and thinking about the top level behaviours more than the code.

Re: TDD is dead. Long live testing.

#73

Post by TimPC »

My biggest problem with TDD is that it tends to take people away from whiteboarding and thinking about architecture and into writing everything as if it were a recursive problem -- write test for base case, code base case, write test for next base case, code next base case, write some significant test case, code general case but often this is completely the wrong pattern for solving a problem. This may be an example of doing it wrong, but it seems to be the practice experts promote when using TDD on a problem (it's very common in both blogging and books).

There are great blog posts of this including Dave Thomas getting horrendously bogged down in writing a Sudoku solver in a situation that could be well handled by going to a whiteboard and thinking about the top level behaviours more than the code.

Re: TDD is dead. Long live testing.

#74

Post by raverbashing »

icebraining wrote: post #50
raverbashing wrote: post #44

While the idea of testing is good, TDD is so full of stupid quirks and BS disguised as "best practices" it's not even funny These often result in slow (and sometimes useless) tests. If you want to use TDD to have more time at the foosball table, great Tests that only test one thing? So I have 30% tests/condition check (or less) and the rest as boilerplate? "and I do not write software test-first" Me neither. It's idi…

The world has not had TDD for a long time, and software got delivered. That's an argument against any kind of improvement; you can replace "TDD" with anything introduced since people started writing software.

The issue I have with TDD fans is that they preach TDD is absolutely necessary for development.

I'm not against improving things, I'm against saying it's "the only true way" and ignoring the shortcomings.

Sure, do your RoR project using TDD, now, doing TDD in C is a whole different problem.

Re: TDD is dead. Long live testing.

#75

Post by kackontent »

basicallydan wrote: post #47

Hear, hear. Dogmatic adherence to any system is dangerous. It goes along with being dogmatic. It's important for developers to read what others have done, see how others have solved problems and stand on the shoulders of giants before thinking for themselves, instead of just blindly accepting "best practice" as the best practice . What I like to do with TDD is use it whenever it's the quickest way to develop somethin…

> If I'm creating an HTTP API and someone else is writing the front-end, I'll create unit tests that spin up my API and make requests to it to ensure I get the correct responses.

That's not unit test though, rather integration or system test.

Re: TDD is dead. Long live testing.

#76

Post by why-el »

michaelfeathers wrote: post #20

This is a stunning opinion considering the fact that there are many Rails shops that can't turn around a build in less than an hour because you can't test models independently of the database.

He did mention fixtures, which speed things up dramatically, so I don't think he shares the same experiences with the Rails shops you are talking about (Who I assume do hit the database since the industry is in favor of factories). Of course fixtures vs factories is a different topic, but you are wrong in your analogy.

Re: TDD is dead. Long live testing.

#78

Post by programminggeek »

michaelfeathers wrote: post #38
h2s wrote: post #34

Earlier quoted context omitted.

Yeah. The hand-wavey reference to advances in parallelisation and cloud runner infrastructure doesn't adequately address the drawbacks of this "post-TDD" approach.

Sometimes I wonder whether the reason he doesn't like TDD is because he inadvertently made it difficult for himself and others in Rails. This is the engineering form of confirmation bias. If you make something hard to do, it's hard to like it.

I think that is part of it. When I tried to TDD existing PHP code, it was pretty awful and I hated testing.

At the same time, I think when you design away as much complexity as possible at the product requirements level, as 37Signals proudly does with their products, it is hard to appreciate the complexity inherent to the requirements in other codebases.

I've seen this with other developers coming into large codebases with lots of complexity and scale requirements wanting to use a simple/naive ORM solution with no caching or worry about query speed/quantity. That solution falls over and they quickly learn that the requirements are more complex than a simple app with a few dozen users.

Basecamp is obviously at a high level of traffic and scaling complexity, but they still work to reduce requirement complexity which isn't always an option if you aren't the product owner.

Re: TDD is dead. Long live testing.

#79

Post by penland »

mattgreenrocks wrote: post #60
tragic wrote: post #52

I can certainly sympathise with the abstinence-only pride and shame cycle. My projects typically start with a test-first approach, which evaporates when the clock starts ticking. It seems to me, first of all, that there's a threshold of software complexity, beneath which writing tests is a net loss in time and productivity. If you have (as I often do) a couple of hundred LOC spread across a few files, with one or two…

> I haven't come across much about good design of tests (suggestions very much welcome) Growing Object-Oriented Software Guided By Tests is worth a start. The authors use TDD, but that shouldn't put you off from learning the theory of separating concerns enough to write fewer tests.

+1 - that's an outrageously good book.

Re: TDD is dead. Long live testing.

#80

Post by mh_yam »

tragic wrote: post #52

I can certainly sympathise with the abstinence-only pride and shame cycle. My projects typically start with a test-first approach, which evaporates when the clock starts ticking. It seems to me, first of all, that there's a threshold of software complexity, beneath which writing tests is a net loss in time and productivity. If you have (as I often do) a couple of hundred LOC spread across a few files, with one or two…

> I haven't come across much about good design of tests (suggestions very much welcome).

I have yet to see a large-scale, popular piece of software written using TDD

Post reply on HN