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

131–140 of 166 posts

Re: TDD is dead. Long live testing.

#131

Post by djur »

peeters wrote: post #106

I used to be dogmatic about TDD. Then I joined a team where management doesn't value unit testing that much, and so I got a lot less religious about it. What I am missing now isn't the test-first mentality. I honestly don't think there's a quality advantage to writing the tests before the code. And the danger of ardent TDD was always investing a ton of time ironing out a unit to perfection, only to realize you missed…

The book Growing Object Oriented Software, Guided By Tests does a good job explaining how to avoid the "missing forests for the trees" problem. The short summary is to use integration and unit tests in tandem, which keeps you focused on the entire feature while also developing carefully tested units. The book explains it better than I do.

Re: TDD is dead. Long live testing.

#132

Post by wpietri »

adrianoconnor wrote: post #16

I dislike mocks. I've never seen the point in testing code against an entirely fictional representation of the most complicated and slow part of the system, just because it happens to be more convenient. Of course it's more convenient. The only compelling reason I can see for mocks is when you've got code that hits external live-APIs that don't give you any real option for automated testing (E.G., reading from and po…

I dislike mocks too; it introduces a lot of duplication that I think is deeply problematic. Automated tests are for me a way to support changing the system easily and safely; lots of mocks often work against that.

But what you're getting is speed. Tests are at their most valuable when they give you quick feedback. As test suite times creep up, people stop running them as much, or at all. I've been on projects where all our tests run in seconds, and it is an enormously different development experience than when they run in minutes.

Re: TDD is dead. Long live testing.

#133

Post by dasil003 »

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.

You also can't be human or probably any animal for that matter. Pattern matching and generalization is how we survive and function in a world that is bigger than us.

Re: TDD is dead. Long live testing.

#134

Post by wpietri »

IgorPartola wrote: post #122
wpietri wrote: post #110

Earlier quoted context omitted.

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 luc…

Agreed. Unit testing requires units.

I also agree that being pragmatic is generally the way to go, but that kind of pragmatism has limits. If I'm too focused on short-term pragmatism, I will let the issues of external systems infect mine. If I'm being longer-term pragmatic, I'll try to keep my code relatively clean and reliable, no matter how kooky the things I'm integrating with.

For example, the first REST integration I do, I may just say "we'll ignore network errors and see what happens". But if I'm doing a few, I'm going to look hard at extracting a reusable layer of code that handles layers, timeouts, partial responses, and the like. And that I will test properly. That way the rest of my code can assume sanity.

Re: TDD is dead. Long live testing.

#135

Post by collyw »

smackay wrote: post #18
chrisdinn wrote: post #10

dhh has spent so much of his career actively leading Rails that it's tough to tell the difference between his personal evolution as a developer and general trends in the industry. I don't think he even attempts to make a distinction in this essay. I worry about a push away from unit tests. I can't imagine having to refactor a large application with only system-level integration tests to work with, especially in a dyn…

It's not so much about moving away from unit tests are more to do with picking the best points at which to test your apps. For web apps the natural points at are the model level and at the client level. For the Django apps I write these tend to be the most stable areas since they are likely to be heavily influenced by user requirements. The result is tests that have a long lifetime and provide better system documenta…

"I have found with TDD that unless you know in advance exactly what you are doing and going to do you will end up writing a lot of tests that get junked".

If you know all that up front, you might as well go with waterfall methodology.

Re: TDD is dead. Long live testing.

#136

Post by beamer99 »

The efficacy of TDD is dependant on language,tooling and experience. You want to spend most of your time writing the problem, AFTER you have thought about it. Developers complain about TDD when they can't think through their problem clearly and use it as a tool to validate bad thinking. TDD in this situation will naturally feel like running in heavy lead boots, since progress will be slow. Very surprised that the test pyramid is not being discussed as much as it should.

Re: TDD is dead. Long live testing.

#137

Post by mh_yam »

anonymousdev wrote: post #115
mh_yam wrote: post #95

Earlier quoted context omitted.

You really don't want to be surrounded by those people. They'll make you hate your life. Unless you are one of them.

You would hate your life if you were surrounded by TDD fanatics? Would you love your life if you had to change huge applications with 100k+ LOC without any kind of testing and if anything breaks at the client, it's your fault? TDD didn't appear out of the void because some wankers want to deride everyone else, it's the ONLY WAY to have tests in the business world because if the features are developed first, the busin…

There's a balance. >it's the ONLY WAY to have tests in the business world

Perhaps in some organizations. I feel sorry if you have to work in such an environment. My company recognizes the value of testing-we have 15,000 acceptance tests and unit tests, and we do TDD perhaps 20% of the time.

I worked at a bank where there were 0 unit tests or acceptance tests. Just some half-assed QA guy going through toy scenarios and pushing the 'approve' button. That's not where I want to be (therefore I quit), but I also don't want to be in an environment where people scream and call me an infidel if I don't do TDD.

Re: TDD is dead. Long live testing.

#138

Post by collyw »

_pmf_ wrote: post #48

The problem is that people think test driven design leads to good design. It does not. It does not even lead to design at all. All it does is create testable code. This code might have good design, or it might not.

Most of the examples I see seem to test the framework rather than the new code.

Re: TDD is dead. Long live testing.

#139

Post by nimblegorilla »

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 think you have it backwards. Non-ruby developers often use static compiler checks as a replacement for proper unit tests.

Post reply on HN