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

Integration tests are a symptom of poor design

facebook.com

Post reply on HN
Print view View original

91–100 of 108 posts

Re: Integration tests are a symptom of poor design

#91

Post by dboreham »

aeorgnoieang wrote: post #89
dboreham wrote: post #59

Earlier quoted context omitted.

>like me, you can't access Facebook wherever you are Wherever it is, it sounds wonderful.

It's just a state of mind man! Funnily enough, it only ever bites me when I want to read something like this. Or use some site or service that requires auth via Facebook. The idea of logging-in to Facebook now, having not done so at all in ... maybe a year? – I just expect to be overwhelmed with the volume and underwhelmed with the significance of whatever it is my 'friends' are posting that it's just easier to never…

I uninstalled the Facebook apps from mobile devices, put it in the blacklist for StayFocusd and just recently enabled U2F authentication. All of that makes it just sufficiently difficult to actually get into Facebook that I only look at it once a day. Curiously Facebook seems to regard difficulty logging in as a serious show stopping bug because while testing U2F I made some failed login attempts. They emailed me several times over the next 24h asking if I needed help logging in. Mo logins mo money..

Re: Integration tests are a symptom of poor design

#93

Post by mikestew »

csours wrote: post #23

Why is testing so confusing? All automated tests (unit, integration, functional ui) are regression tests. They are not there to find problems when you write code; they are there to surface problems when you change code. The distinction between the types of test help you find at what level the problem lies. One of the best skills of the troubleshooter is to break down interactions into layers, and then troubleshoot ea…

All automated tests (unit, integration, functional ui) are regression tests

I wish I had a way to get this across to people. Even Glenford Myers, who I otherwise have great respect for, wrote some forty years ago that a test that doesn’t find any bugs is a waste of time. Every formal test I’ve written is a “waste of time” because if there’s a bug, I already found it while writing the test. The actual test is there simply to make sure the bug doesn’t come back.

If we can’t get this simple idea right, we can’t have a productive discussion on unit tests vs $OTHER_TESTS, etc.

Re: Integration tests are a symptom of poor design

#94

Post by dang »

throwaway_f8ed wrote: post #40

Disclaimer: I mean no offense. I am yet to see one production-ready real-world code example from such gurus of design of the past. Kent Beck, Bjarne Stroustrup, Scott Meyers. I think that in 2017 you shouldn't be entitled for your opinion about design if you have nothing to back up your cases. Sadly, this also covers me with this throw-away account, but bear with me for a while. When they started their journey the wo…

Given the context, this comment is a personal attack. That's not ok here and I've banned the account.

If you really meant no offense, you need to work harder at giving others the benefit of the doubt and watching out for ignorance masquerading as knowbetterness. We all need to work on these things, of course, but comments that go below minimum levels are not welcome on HN.

https://news.ycombinator.com/newsguidelines.html

Re: Integration tests are a symptom of poor design

#95

Post by KentBeck »

mabbo wrote: post #29

The presumption here is that you are a team of Kent Beck's. Mine isn't. Yes, with a lot of work and time, we can come up with very good abstractions so that all code is easy to understand and follow and unit tests are all we need. But we don't have that time, nor often the skill needed. What we need is a running product, today, for our customers. Integration tests are a crutch. Some of us need crutches. And I don't f…

Hang on a minute. I'm both Superprogrammer and a washed up old has-been? This is getting confusing.

There's no shame for me in using integration tests. They just hint at an alternate universe where the design is different and they either disappear entirely or become unit tests. So today isn't the day that happens. Okay. "Perfect" is a verb.

Re: Integration tests are a symptom of poor design

#96

Post by mannykannot »

KentBeck wrote: post #82
mannykannot wrote: post #75

Earlier quoted context omitted.

After reading the article, I thought the person posting to HN had either misunderstood it or misappropriated it for his own agenda - but then I saw that it was apparently posted by the author himself.

There's a challenge finding the right headline when posting to HN. My last few posts had very literal headlines and went nowhere. I amped this headline up a bit while making sure it was still honest and, looky here, it got more attention. Now I have to decide how I feel about the difference.

FWIW, it doesn't bother me. Perhaps phrasing amped-up headlines as questions would forestall at least the more moderate wing of the clickbait squad?

Re: Integration tests are a symptom of poor design

#98

Post by bonesss »

Chaebixi wrote: post #33
aeorgnoieang wrote: post #14

Earlier quoted context omitted.

I don't think you're really disagreeing with Kent. And I haven't found that integration (system) tests have a higher ROI – because they're usually much more expensive to write and maintain. And they can be more brittle than your actual code. If your code depends on an external service, should your integration test actually make a (test) request to the real live service endpoints? Maybe! But the more 'real' the test i…

> And they can be more brittle than your actual code. The brittlest tests I've ever seen have been mock-heavy unit tests. Some of them amount to little more than file-change detectors. Those tests can fail massively even when everything still actually works. They cry wolf so often the team ends up trained to unthinkingly change them so they "go green." > But I think I get what he's getting at in terms of – ideally –…

> The brittlest tests I've ever seen have been mock-heavy unit tests

Not to knock mocking in general, but the need to replace multiple things at once to test one thing is just a big design smell, and I agree: their usefulness tends to be very limited in terms of logic exercised.

Call me a fuddy-dud, but I'm generally working with dependancy injection when doing OOP so stubbing out app layers for test contexts feels kinda natural, and I prefer to make my test mocks the old fashioned way: manually using inheritance. It keeps the pain high if I'm doing something wrong, keeps the tests focused, and means I'm hammering the objects design from the POV of an inheritor/reuser from the get-go.

I've noticed that the additions necessary to make a manual mock tend to be a good predictor of future changes required in the code-base, while framework based mocks tend to spend a lot of time re-declaring things we already know.

Re: Integration tests are a symptom of poor design

#99

Post by bonesss »

maxxxxx wrote: post #46
aeorgnoieang wrote: post #14

Earlier quoted context omitted.

I don't think you're really disagreeing with Kent. And I haven't found that integration (system) tests have a higher ROI – because they're usually much more expensive to write and maintain. And they can be more brittle than your actual code. If your code depends on an external service, should your integration test actually make a (test) request to the real live service endpoints? Maybe! But the more 'real' the test i…

"And I haven't found that integration (system) tests have a higher ROI – because they're usually much more expensive to write and maintain." I think the worst code bases to modify are the ones with heavy use of mocking and dependency injection. You still get no feedback about the behavior when run against the real system and you have to maintain a potentially complex mock.

I think the issue you're describing, a massive variance in test and system behaviour, is symptomatic of a poor delineation of the unit/integration test dichotomy. It's almost a skill within a skill, but the moment a mock starts taking on some life or complexity is a moment you should be backing out and refactoring.

Complex mocks shouldn't exist. Mocks of complex interfaces should almost entire be sustainable by your domain objects if they're exposed to your testing 'datalayer'. So if they're required to test, and I've seen many codebases where that's true, then you've generally got a major design issue that is unaddressed in the main codebase.

Personally I use mocks very sparingly coupled with a few strategic stubs (ie hard coded "databases" of domain objects), and almost always code them manually by hand. That way it's very clear if I'm doing something dumb, the sytems DI is leveraged, and the mock is highlighting design issues in a re-use/inheritance context.

Re: Integration tests are a symptom of poor design

#100

Post by bonesss »

crdoconnor wrote: post #76
WalterSear wrote: post #48

Earlier quoted context omitted.

>It's a terrible idea not to. If your code isn't coupled to someone else's code your code isn't doing anything useful. Paradoxically, you want your tests separate from the external inputs, because complete control over the inputs is required to systematically and programmatically hit every edge case with every pass of your test suite. You also need the modularity in your tests and code, so you can fix and replace 3rd…

What you are arguing for is that code should be loosely coupled. I generally agree with this (although, like DRY, its validity is context sensitive and one can take this approach too far). This is an orthogonal question to whether code should be tested realistically or not, however. You want to test your code against real external inputs for additional realism as well as mocks that are as realistic as possible to iso…

> ...You want to test your code against real external inputs for additional realism as well as mocks that are as realistic as possible...

Ding ding: it's not either/or, it's both/and across a spectrum from dumb to smart to dumb again.

If you use a google rest API in something serious you want to be able to model the error conditions of that API, you also need to verify the current status and content of that API, you also need to verify your apps behaviour separately for both cases.

Loose coupling and DI are important to strike the right balance, but fundamentally you're either testing your solution or you're not.

Post reply on HN