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

121–130 of 166 posts

Re: TDD is dead. Long live testing.

#121

Post by wpietri »

slavoingilizov wrote: post #65
mwilliamson wrote: post #25

I think a problem is that we tend to overgeneralise our own experience. When we try out ideas, such as TDD, we (hopefully) get a good feel for how they work (or don't work) for us. Reading articles or getting advice might help us to understand and use those ideas better, but the impression is still based on your personal experience. That's fine when you're talking about how you like to work, but I think it comes unst…

Yes, but if you don't generalize you can't have a captivating title and can't reach the HN frontpage.

And let's not forget adding drama. It's not just that my generalization is right, it's that everything you have said is fucking wrong.

Because the world doesn't have enough drama.

Re: TDD is dead. Long live testing.

#122

Post by IgorPartola »

wpietri wrote: post #110
programminggeek wrote: post #70

What DHH describes is called the test pyramid ( http://martinfowler.com/bliki/TestPyramid.html ), which despite the fact that DHH seems to dislike Uncle Bob, it is something Uncle Bob has demonstrated and advocated multiple times in very sensible ways. The bigger thing DHH doesn't mention or explain is that Basecamp is designed to be intentionally simple. Much of the complexity that you get in client work where you d…

Another thing I think DHH has missed here is that his experience is not particularly broad. His achievements are very impressive, but if I recall rightly, he started Rails before finishing his CS degree, and that's basically all he's done since. One of the core assumptions of Rails is having a database. A lot of it is focused on turning HTTP requests into SQL requests, and turning SQL responses into HTML. Which is fi…

It's a lot easier to write unit tests for, you know, units. For example, if you have a date-to-readable-string conversion library, you can test the crap out of it since it's input is a date object and its output is a string. It's a unit of code, so all the testing that's required is unit testing.

On the other hand, when the "unit" you are testing relies on six external API's and your own database to work, best of luck to ya. It's not a unit at this point, it's the glue that holds other units together. It is important to get it right, but given how many different combinations of failure modes there are you are not going to test it all and you are not going to get it right. Mocks/fakes do not make this stuff much better as timing and latency are important too. What if the UPS address service you are using doesn't return an error but times out? Now your production code has to include enough of a framework for simulating network errors.

I do agree with TFA: TDD is a niche thing that has been so widely embraced for all the wrong reasons that it's no longer useful even in the niche. Also, system-wide testing is very important as well and the tooling for it sucks. My rule of thumb is to be pragmatic about automated testing: test the things that will give you the greatest ROI in terms of time/effort/time-to-market/etc. but don't be religious about it. The tests are not the end product and should not be treated as such.

Re: TDD is dead. Long live testing.

#123

Post by Silhouette »

rhizome31 wrote: post #23

> Over the years, the test-first rhetoric got louder and angrier, though. More mean-spirited. Where are those mean TDD zealots? Can you point me at blog posts or mailing list messages displaying such behavior? I've never seen it personally. On the other hand, now and again a blog post like this comes up that's full of disdain towards the practice of testing first. I do TDD because it helps me get my work done. I'm ha…

Where are those mean TDD zealots? Can you point me at blog posts or mailing list messages displaying such behavior?

"My thesis is that it has become infeasible, in light of what's happened over the last 6 years, for a software developer to consider himself 'professional' if he does not practice test driven development."

Robert C. Martin, 2008

http://www.infoq.com/interviews/coplien-martin-tdd

Re: TDD is dead. Long live testing.

#124

Post by qwerta »

I use TDD extensively and it helps me a lot. It works like version control for progress. It splits problem into small parts which can be solved separately. I can work on very hard problems, without fully understanding them.

But I agree: for simple CRUD web apps TDD is overkill.

Re: TDD is dead. Long live testing.

#125

Post by thinkpad20 »

ArbitraryLimits wrote: post #82
twerquie wrote: post #54

> Test-first units leads to an overly complex web of intermediary objects and indirection in order to avoid doing anything that's "slow". Like hitting the database. Or file IO. Or going through the browser to test the whole system. It's given birth to some truly horrendous monstrosities of architecture. A dense jungle of service objects, command patterns, and worse. This is DHH's central argument, he is once again de…

> In Ruby, unit tests stand in place of static compiler checks. I haven't heard a strong argument against them nor a replacement for them. How about static compiler checks? :)

I don't know a great deal about ruby, but I'd wager that the way it's designed would make static type checking essentially impossible. And you probably understand this, but still. Dynamic languages allow fundamentally unsound types, for example:

    def foo(x):
        print x
        return foo
This function has no computable type (in a standard system anyway); it's "a -> a -> a -> ...". However it's perfectly obvious what it does, and conceivable that it or similar functions might exist and be useful in actual code. Dynamic languages allow behaviors which are impossible in statically typed languages (properties created at runtime are another example).

Of course, one could use gradual typing to get around some of this.

Re: TDD is dead. Long live testing.

#126

Post by Singletoned »

b_mannix wrote: post #42
Singletoned wrote: post #35

I think he's conflating the separate concepts of Test Driven Development and Unit Testing. They can be done independently of each other. I agree that many other people also conflate them, and are zealots for (or against) them together, but they are still separate concepts. He does make some good arguments against Unit Testing, but he makes none against TDD.

Interesting. I agree with everything you wrote until the last sentence. I think he made some great arguments against TDD, but none against unit testing.

Really? What did you think was an argument against TDD?

> Test-first units leads to an overly complex web of intermediary objects and indirection in order to avoid doing anything that's "slow".

This is an argument against unit testing (and is a good example of the conflation). Personally I do TDD with slow, system tests, that mainly are testing business requirements.

He makes a couple of points that some TDD people are rabid, but that is just an argument that some people are jerks. It's not an argument against TDD. (And exactly the same is true of Unit Testing).

Re: TDD is dead. Long live testing.

#127

Post by wpietri »

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 started doing TDD in 2000, so I'm pretty comfortable with it, and I totally agree with you on the threshold of complexity. For me, TDD is a way to get a better outcome for a project. It has big benefits, but it also has costs. If the costs are above the benefits, I won't do it.

The obvious case is a single-use command-line shell script. Small code, single author, minimal duration, no reuse: automated testing isn't worth it. But if I'm building a large, multi-programmer, long-lasting project, with lots of changes along the way, I'll do a lot of automated testing.

The tricky thing is that many projects start out small and then unexpectedly grow. You start out saying, "This doesn't need a test." And then it becomes, "Well now testing this is kinda hard and I don't have the time." And gradually you end up with an untestable legacy system that is a nightmare to work on.

So the deal I make now is that I'm happy to do quick and dirty things as long as I get to throw away the code or clean it up properly when I decide the time is right. Basically, I'm willing to take on technical debt as long as I know I can declare bankruptcy when that's the right choice.

Re: TDD is dead. Long live testing.

#128

Post by djur »

ArbitraryLimits wrote: post #82
twerquie wrote: post #54

> Test-first units leads to an overly complex web of intermediary objects and indirection in order to avoid doing anything that's "slow". Like hitting the database. Or file IO. Or going through the browser to test the whole system. It's given birth to some truly horrendous monstrosities of architecture. A dense jungle of service objects, command patterns, and worse. This is DHH's central argument, he is once again de…

> In Ruby, unit tests stand in place of static compiler checks. I haven't heard a strong argument against them nor a replacement for them. How about static compiler checks? :)

Still not an adequate replacement for unit tests. The compiler can prove that your code is correct but not that your logic is.

Re: TDD is dead. Long live testing.

#129

Post by itsmonktastic »

I don't think people have a great consensus on what "TDD" really means, so there's a lot of "Do you do TDD? You should do TDD!", people taking mixed approaches that they sort of make up or copy from a quick blog post, then deciding that TDD sucks or rules.

For example, this article seems to think TDD is mostly about unit tests (and I've definitely seen the same opinion elsewhere). But somewhere else, specifically GOOS[0], the TDD cycle always starts with an end to end test, with an inner unit test/development cycle to get the test passing. I think this is really important, because if you don't have end to end tests, it's a lot harder to refactor your code in significant ways, and can leave you with extra work maintaining all of your unit tests.

Another thing is "fast tests" as resulting in "a dense jungle" of objects. At least in GOOS, the assertion is that a larger network of small objects is better than a smaller network of large objects. I'm not going to argue the benefits of one way or another, but what I mean to point out is that (at least some) people use TDD because they think it will help them write a more maintainable code base, and aren't just writing code to make their tests fast for the sake of fast tests.

[0]http://www.growing-object-oriented-software.com/

Re: TDD is dead. Long live testing.

#130

Post by agentultra »

The pyramid works rather well in my experience.

I still practice TDD though. When I started working on a binary tree space-partitioning algorithm a while ago for my talk at Pycon 2014 I started just writing code and spent a precious couple of nights banging my head against the wall because it was always off and would come up with intermittent errors. I had figured that I knew the data-structure and algorithm well enough and this is one-off code so who cares? So when I was desperate I had told a couple of good friends about my problem and they reminded me: I hadn't written the tests figuring that I'd save myself the time.

TDD has just been a part of my process for years now that I don't think I can even write good code without it. Even in statically type-checked languages. The practice forces me to specify the contracts and behaviors of each piece of my code before I write a single line to implement it. That loop of test, write, pass/fail offloads a tonne of complexity from my mind. It also helps me to discover where my assumptions were wrong in the design process when I notice some tests require too many mocks/stubs/assumptions about state or are simply brittle. Along with a keeping a rigorous development journal it's one of the most powerful tools in my arsenal.

Post reply on HN