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

111–120 of 166 posts

Re: TDD is dead. Long live testing.

#111

Post by _pmf_ »

huherto wrote: post #31
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 find stubs occasionally useful. But I don't get mocks. http://martinfowler.com/articles/mocksArentStubs.html

That's the money link. People who save time by using mocks instead of stubs are deferring design problems to later stages, which is really bad. When I'm only responsible for my module and don't give a shit about the system as a whole, then mocking is fine. But in this case, the development process is toxic.

Re: TDD is dead. Long live testing.

#112

Post by mercurial »

edwinnathaniel wrote: post #93
mercurial wrote: post #62

Earlier quoted context omitted.

> 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. Maybe your name is David, and you don't do test-fir…

The thing is... in Rails app, the Controller is slowly becoming THE service layer. In the past literatures written mostly for enterprise projects, Service layer ( http://martinfowler.com/eaaCatalog/serviceLayer.html ) answers to multiple interfaces. Fast forward to today, Rails Controllers become the API which other interfaces can consume via JSON, XML, or even HTML or simply stream of texts if configured. If you can…

Uh. In any complex application, you write services which are responsible for various business needs, and whose responsibilities only loosely overlap the way your webapp is accessed from the outside. You may even have services only used by other services.

And obviously, stuffing your business logic along with your web glue (whatever concrete representation you're sending to the outside, you're still stuffing parameters in a template, essentially) still violates SRP. Not to mention that it makes it utterly impossible to reuse outside of your web application, something which is sometimes desirable.

Re: TDD is dead. Long live testing.

#113

Post by erewh0n »

mbillie1 wrote: post #91
erewh0n wrote: post #4

I fully agree that TDD has turned into a cargo cult obsession for many developer shops. The benefits of unit tests are usually for the developer, but in over abundance can lead to inflexibility and debt when your system needs to change.

> in over abundance can lead to inflexibility and debt when your system needs to change. I hear this argument a lot, and I think it is absolutely incorrect. If tests are hindering your system then you're just doing it wrong. It's like saying "climbing rope is a hindrance for the rock climber, since I have tied gordian knots around my feet and now cannot move." TLDR doing something badly doesn't mean the thing you hav…

Yes, this is really what I mean by "over abundance". I'm suggesting that excessive application of unit test "fundamentalism" can lead to a variety of problems. A particular manifestation of what you describe as "doing something badly".

Re: TDD is dead. Long live testing.

#115

Post by anonymousdev »

mh_yam wrote: post #95
anonymousdev wrote: post #85

All the guys crying about the prevalence of TDD are the ones who are lucky enough to live in a tech hub from a developed country. In my area I'm the only one who knows about TDD/BDD. You want to know how testing is done here? - 80% of projects have no testing whatsoever - 20% are manually tested by students paid with 3$/hour Unlike others, I would love to be surrounded by "TDD zealots or fanatics".

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 business guys will say "let's skip the tests to cut the costs".

Re: TDD is dead. Long live testing.

#116

Post by wpietri »

JunkDNA wrote: post #98
edwinnathaniel wrote: post #81

Earlier quoted context omitted.

Why moving toward more client-side JS complicates testing further?

Because now you're introducing an interface when previously you had shared objects all on the server in a single codebase. For example, let's say my JavaScript client works with a "User" object delivered via REST API from the server. Let's say I change Django's User model object to modify some existing attribute. Previously, all my Python code's tests would now use this updated model object and I could simply run my…

I'm personally not a big fan of mocking; it introduces a lot of duplication into the system. On the other hand, I'm not a big fan of testing a fully integrated system unless you've TDD'd everything from scratch, because then people let systems get slow enough to make tests too slow to maintain a good pace.

If you're already in the "integrating with slow things" problem space, then one solution is to automatically generate the mocks from real responses. E.g., some testing setup code calls your Django layer to create and fetch a User object. You then persist that so that your tests run quickly.

And yeah, I'll definitely use end-to-end smoke tests to make sure that the whole thing joins up in the obvious spots. But those approaches are slow and flaky enough that I've never managed to do more than basic testing through them.

Re: TDD is dead. Long live testing.

#117

Post by prawks »

JunkDNA wrote: post #49

I've been slowly coming to this realization myself lately, I thought our situation was just outside the mainstream of what most people work on, but maybe not. Our team builds data-intensive biomedical web applications (open source project for it all here: http://harvest.research.chop.edu ). Much of our UI is data-driven, so many of the bugs we encounter are at the intersection of code, config, and unique data circums…

> the intersection of code, config, and unique data circumstances

I'm sure I'm way over-simplifying here, but those sound like missed edge cases? I can imagine they'd be difficult to predict, regardless.

Re: TDD is dead. Long live testing.

#118

Post by jarrett »

edwinnathaniel wrote: post #107
jarrett wrote: post #101

Earlier quoted context omitted.

Largely because more of the automated integration testing has to be done with a headless browser, e.g. Poltergeist. If you have no JS in an important area of your site, you can integration test it without a headless browser. Your test process models HTTP requests as simple method calls to the web framework. (E.g. in Rails, you can simulate an HTTP request by sending the appropriate method call to Rack.) The method ca…

Yes, I've known about the headless proposition for a while. Splitting front-end and back-end tests is desirable. > Worst of all, headless browsers still can't truly test that "the user experience is correct." This is the claim from the old Joel Spolsky article about automation tests but should not be the ultimate dealbreaker. Nobody claims you should rely on automation-tests 100%. Automation-tests test functionality…

> Splitting front-end and back-end tests is desirable.

I don't feel confident without integration tests. An integration test should test as much of the system together as is practical. If I test the client and server sides separately, I can't know whether the client and server will work together properly.

For example, let's say I assert that the server returns a certain JSON object in response to a certain request. Then I assert that the JS does the correct thing upon receiving that JSON object.

But then, a month later, a coworker decides to change the structure of the JSON object. He updates the JS and the tests for the JS. But he forgets to update the server. (Or maybe it's a version control mistake, and he loses those changes.) Anyone running the tests will still see all test passing, yet the app is broken.

Scenarios like that worry me, which is why integration tests are my favorite kind of test.

> Automation-tests test functionality of your software not the look-n-feel or user-experience.

It's not about the difference between a drop shadow or no drop shadow. We're not talking cosmetic stuff. We're talking elements disappearing, being positioned so they cover other important elements, etc. Stuff that breaks the UI.

> The problem between JS and CSS shouldn't be that many either

Maybe it shouldn't be, but it is. I'm not saying I encounter twelve JS-CSS bugs a day. But they do happen. And when they make it into production, clients get upset. There are strong business reasons to

> If you have tons of this then perhaps what's broken is the tools we use? or perhaps how we use it?

Exactly. I think there's a tooling problem.

Re: TDD is dead. Long live testing.

#119

Post by basicallydan »

kackontent wrote: post #75
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.

Right you are. I tend to be quite lazy when distinguishing between types of tests, but as @yeukhon said, TDD doesn't distinguish :)

Re: TDD is dead. Long live testing.

#120

Post by wpietri »

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…

Interesting! Those benefits are also part of it for me.

The quality advantage I have noticed for TDD comes in better coverage. If I'm doing test-after, I already think the code works, so it's harder for me to notice the places where my thinking is wrong. If I'm doing test-first, I start out more skeptical and clear-headed.

I also think I design better, and for similar reasons. TDD starts me focused on the how the code appears from the outside, and then I make the implementation conform to that. If I start with the implementation, it's easier for me to get a little slack about the API; because my head is full with how it works internally, more of that can end up in the external interface.

Post reply on HN