Live data from Hacker News

Integration tests are a symptom of poor design

facebook.com

71–80 of 108 posts

Re: Integration tests are a symptom of poor design

#71
post #42

Earlier quoted context omitted.

A long time ago we had Scott Meyers for a week long workshop. He definitely knew his stuff and showed a lot of real world experience. But with a lot of "gurus" I have my doubts. A lot of advice from Scrum gurus falls apart when it meets reality. I guess the ultimate advice should be given by people like Linus Torvalds who run large projects.

I will never question that he knows language and its obscurities, but real world in his case is even more different. Scott Meyers is a C++ guy. I will bet that nowadays most of C++ programmers are in game development, HFT or other computationally expensive performance oriented areas, and there is this data-oriented design movement which goes against almost everything he ever said. There are entire constructs of langu…

Data-oriented programming is just one optimisation technique, not a revolutionary design movement.

Re: Integration tests are a symptom of poor design

#72
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.

I always assumed that warning was just J&J covering their ass.

Re: Integration tests are a symptom of poor design

#73
post #70

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…

Stroustrup invented C++ and he's actively developing and designing it. He also almost exclusively talks and writes about C++, he's not telling you anything about integration tests. You just seem ignorant by including his name on that list.

Yeah, I doubt he writes any tests at all - unit or integration.

Re: Integration tests are a symptom of poor design

#75
post #65

Earlier quoted context omitted.

No offense taken, but let me add this: I too initially felt a bit weird about the insinuation that "Integration tests are a symptom of poor design", but it's worth pointing out that that's not really the title of his FB note: it's '"Unit" Tests?'. * In fact, going back and reading it a 2nd time, I can't really find anywhere where he's saying you're "doing it wrong" if you're writing integration tests - in fact he say…

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.

Re: Integration tests are a symptom of poor design

#76

Earlier quoted context omitted.

>That's a terrible idea. You've now coupled your tests to someone else's code. 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. Moreover, you should test against the code your code is coupled to as realistically as possible, which ideally means testing against the real thing.

>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 isolate the external inputs and remove a potential source of test instability.

Re: Integration tests are a symptom of poor design

#77
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.…

And if all your tests are unit tests, you can't swap to using a sonic ear cleaner without losing your test coverage.

Re: Integration tests are a symptom of poor design

#78

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…

Did you really read the piece? The reason I ask is that what he wrote and what you wrote are essentially the exact same:

    I’m happy to write integration
    tests. I insist on it. But a 
    part of me registers the need 
    for integration tests as a 
    failure or limitation of my 
    design skills.
(That's how I feel about integration tests, too — which I always use.)

Re: Integration tests are a symptom of poor design

#79
post #49

Earlier quoted context omitted.

> You've now coupled your tests to someone else's code. Your code is coupled to someone else's code. Which yeah, can lead to a lot of problems, but code that doesn't talk to someone else's code is usually not very useful.

> You've now coupled your tests to someone else's code.

Right, but what I'm saying is, it's even worse than that. Not only are your tests coupled to someone else's code, but your code itself is so coupled.

Re: Integration tests are a symptom of poor design

#80
post #51

Earlier quoted context omitted.

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.

> the body's own wax removal process is good enough It really isn't, though. If I go more than a few days without cleaning my ears they get really crusty and it gets harder to hear.

Fascinatingly, you are probably suffering thus due to very specific genetics, not bad hygiene, personal variation in earwax, or an inherent quality of earwax: https://en.wikipedia.org/wiki/Earwax#Physiology
Post reply on HN