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

21–30 of 108 posts

Re: Integration tests are a symptom of poor design

#21

Post by jdbernard »

aeorgnoieang wrote: post #15
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.…

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 ...]

I think the point was to notice the continuum between completely fake stubs that only have enough "real" behavior to facilitate unit tests and a full-fledged production scenario. Integration tests are not the same as production, but they are much closer than unit tests. In integration tests as much is real as possible vs. unit tests where as little is real as possible.

Re: Integration tests are a symptom of poor design

#22

Post by taeric »

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 mutable state is... well, unnecessary? It didn't even really do anything other than signal to a certain crowd that he is on their side.

Integration tests may be a symptom of poor design. I don't see it, though. Integration tests should exist to test the assumptions that your unit tests rely on. Because, by necessity, your unit tests will be making assumptions about the rest of the systems they interact with. To claim that some "pure" design can get you away from needing to test those assumptions is interesting debate starting rhetoric, but a dangerous goal to put in people's minds.

Re: Integration tests are a symptom of poor design

#23

Post by csours »

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 each layer.

Organizing tests in a similar fashion aids in troubleshooting.

Re: Integration tests are a symptom of poor design

#24

Post by taeric »

aeorgnoieang wrote: post #15
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.…

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 ...]

If you aren't sending real orders through your systems.. you are waiting for your customers to find and report all problems. Right?

This is actually a strength of a QA team. They can build test plans and execute them on a different technology than your Dev team built the system with and on. This is also why acceptance testing is so important. You want to get as close to possible as capturing "in the wild" users using your system as you can.

Re: Integration tests are a symptom of poor design

#25

Post by dgritsko »

preordained wrote: post #7

Eh...if you have a REST API for instance, If I'm an ardent user of your API I'd sure feel a hell of a lot better if you were testing at the REST layer. I'm sure your mocks for your internal helper classes are really swell, but being a dev It really doesn't make me believe the thing is actually working. https://twitter.com/kentcdodds/status/628658648001048577

That's a great tweet. Another one of my favorites illustrating the same point:

https://twitter.com/thepracticaldev/status/68767208615275315...

Re: Integration tests are a symptom of poor design

#26

Post by mannykannot »

closeparen wrote: post #10

The “benefit” of unit tests telling you exactly where the problem lies is not compelling. All tests should always be passing on master, therefore the problem lies in “git diff master.” If you can’t tell where the problem is that’s breaking an integration test, your changeset is too large or there are too many layers of indirection. Approximately all of the bugs I encounter in real life would have been prevented by in…

>95% of our test code mostly just exercises its own mocks.

How much time and effort goes into testing and otherwise validating the mocks?

Re: Integration tests are a symptom of poor design

#27

Post by tuan »

Making Transaction mutable usually means its internal state is not 100% controlled by its implementation. The consumer of a Transaction object might be able to manipulate its state in an expected way (e.g. calling mutation methods in an unexpected ordering) and makes it invalid. So the unit test suite you write for Transaction will never cover all cases. You need to test Transaction in the context where it's used as well, e.g. the Account example. That means when you're writing tests for Account, you are actually testing Transaction at the same time. That's probably why it feels more like an integration test than a unit test.

Re: Integration tests are a symptom of poor design

#28

Post by unclewaltr »

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.

Yeah, but it's so satisfying to see what you've produced.

Re: Integration tests are a symptom of poor design

#29

Post by mabbo »

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 feel like I should be ashamed to need one sometimes.

Re: Integration tests are a symptom of poor design

#30

Post by jondubois »

Different people tend to have completely different ideas about what an integration test is.

At one extreme, some people think it means that you have your entire system running and then you have some headless bot simulate clicks and evaluate the system's behavior based on the UI...

From my point of view, any test that traverses through the logic of more than one kind of object is an integration test. Primitive types don't count.

I actually find integration tests much more useful than unit tests. It's unusual for me to come across a unit of code that is so complex on its own that it needs to be tested in isolation. I think that simple units of code is actually a sign of good de

Post reply on HN