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

81–90 of 108 posts

Re: Integration tests are a symptom of poor design

#81

Post by KentBeck »

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…

Thank you for letting me know how I appear to you. I don't agree that my point of view is obsolete or that I am not entitled to an opinion about design. Judging what I write based on my age led to you, as other commenters have pointed out, missing the point of my post.

Your point about up-to-date examples is well taken. Finding good examples is the hardest part of technical writing for me. As I work on Facebook and Instagram I will keep my eyes open for clear examples of the same principles, because the principles really are the same regardless of shifts in technical fashion. You'll have the opportunity to learn that in the years to come.

Re: Integration tests are a symptom of poor design

#82

Post by KentBeck »

mannykannot wrote: post #75
vlunkr wrote: post #65

Earlier quoted context omitted.

I feel like some of these comments are just reading the title and immediately posting their disagreement. I'm with you, he says he writes integration tests himself. There's nothing controversial about this post, it's actually pretty interesting.

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.

Re: Integration tests are a symptom of poor design

#83

Post by AstralStorm »

ddalex wrote: post #6

IMHO integration tests are not there to validate the functionality that you're building - Kent is right here, if you rely on integration tests to find bugs, either your modules are either, or your design is bad (e.g. cross-module code paths that break encapsulation, etc). Integration tests are a god send when refactoring something that used to work in the first place. I'm currently switching 3rd party API providers i…

In real life, you cannot depend on encapsulation or especially documentation. Interesting behaviour is left undefined or not documented. (This including such hairy things to test like thread safety and reentrant behaviour.)

Like C++ itself it allows implementing freedom. The result is that you get to actually test any assumptions you make.

Re: Integration tests are a symptom of poor design

#84

Post by AstralStorm »

taeric wrote: post #22

I'd have to register my vote on this not clearing things up. All it did was talk about relatively simple sections of code with well understood boundaries. Instead, I often find people that try to make "units" of code not "Money" or "Transaction" but crap like "WellsFargoTransaction" or "EuroToUSDollarTransaction" complete with separate classes for each of the things that those imply. And the amusing dig against mutab…

About the only such pure design would then be fully formally verified and specified, also across module boundaries. Good luck with that.

Re: Integration tests are a symptom of poor design

#85

Post by AstralStorm »

matt_sales wrote: post #60
didibus wrote: post #53

GIVEN a function that returns one or zero, which is fully unit tested. GIVEN a function that divides one number by another, which is fully unit tested. WHEN I integrate both functions together. THEN I should get back a number. This is why you need integration tests. Interaction of fully tested units does not guarantee that they can be integrated together in arbitrary ways without the possibility of bugs being introdu…

you're missing a unit test case for your division function -- the case of 0. That test will reveal the function's domain is non-zero numbers. And you know this because you got the fast feedback from your unit test. No integration test using 0 necessary unless you want to test the failure scenario. BTW, nobody is saying not to use integration tests. But unit tests are faster, more stable, and easier to maintain and ex…

Hmm? The division function actually works as defined by throwing a floating point exception, returning one of infinities or other well defined behaviour

It's the test of the user of the function that is incomplete.

Re: Integration tests are a symptom of poor design

#86

Post by draw_down »

WorldMaker wrote: post #17
pavement wrote: post #8

Networked resources have listeners. Listeners have ears. Ears have wax. A unit test verifies that your Q-tip is made of cotton, and that the cotton is soft and small enough to fit inside an ear to a depth that will fetch wax. Another unit test might confirm that a swabbed substance is actually ear wax, by reporting the qualities of a verified sample of earwax, and maybe also a sample of candle wax as a true negative.…

That's an interesting choice of analogy given that boxes of Q-Tips warn you to never try cleaning your ears with a Q-Tip and so do most professionals: http://time.com/4290668/q-tip-ear-wax-removal/ Current professional wisdom is that you shouldn't even bother cleaning your ears because wax buildup is healthier and the body's own wax removal process is good enough.

This is... not a good point.

Re: Integration tests are a symptom of poor design

#87

Post by aeorgnoieang »

pavement wrote: post #32
aeorgnoieang wrote: post #15

Earlier quoted context omitted.

This was a good metaphor but I don't understand the last line. Our tests can never 'really' clean 'real ears' can they? [Actually, that's kind of an interesting idea. Send a real order thru your inventory, order management, etc. systems ...]

Payment processors frequently conduct "no-capture" test transactions for authorizations of possibly $1, before tokenizing CC info. Arguably, this follows the pattern of an integration test. Ecommerce providers often follow a process of cycling an immaterial test product through a real credit card for pennies, with a petty cash credit card, to exercise the purchase/refund cycle, end-to-end, depending on the activities…

> Ecommerce providers often follow a process of cycling an immaterial test product through a real credit card for pennies, with a petty cash credit card, to exercise the purchase/refund cycle, end-to-end, depending on the activities of the project.

That sounds familiar. I'm sure that was being done at the last place I worked, an e-commerce 'agency'.

Re: Integration tests are a symptom of poor design

#88

Post by aeorgnoieang »

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.

> complex mock

That's a smell for sure. I've got a codebase with lots of 'mocks' and a good amount of dependency injection, but I don't feel like it's hard to modify. In fact, the mocks and dependency injection make testing possible. But then all of the mocks are really dumb, e.g. implementing an interface in the 'dumbest' way possible.

The most complex mock behavior I have is return a value supplied as a parameter to this object's constructor. The mock then is really just a way to explicitly encode assumptions about (possible) behavior of whatever it is being mocked or injected.

Re: Integration tests are a symptom of poor design

#89

Post by aeorgnoieang »

dboreham wrote: post #59
aeorgnoieang wrote: post #2

A link (via Internet Archive) in case, like me, you can't access Facebook wherever you are: https://web.archive.org/web/20171206200104/https://www.faceb...

>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 login again.

Re: Integration tests are a symptom of poor design

#90

Post by taeric »

AstralStorm wrote: post #84
taeric wrote: post #22

I'd have to register my vote on this not clearing things up. All it did was talk about relatively simple sections of code with well understood boundaries. Instead, I often find people that try to make "units" of code not "Money" or "Transaction" but crap like "WellsFargoTransaction" or "EuroToUSDollarTransaction" complete with separate classes for each of the things that those imply. And the amusing dig against mutab…

About the only such pure design would then be fully formally verified and specified, also across module boundaries. Good luck with that.

Completely agreed.

It is funny, because I do think this is why we are constantly reimplementing things in the new languages, instead of finding ways to connect old programs.

That is, people are so worried about bugs in hooking grep up to their system, that they instead reimplement all the bugs building grep into their system. (Where grep is an easy to type example from my phone. :) )

Post reply on HN