[pavement]

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.

An integration test verifies whether you are allowed to swab a specific person's ear, that they still HAVE at least one ear (but check for both, YES. EVERY SINGLE TIME.), that the ear is healthy enough to tolerate a cotton swab, that the person will hold still, and wait for you to finish swabbing (and emergency procedures for what happens if they violently react to suddenly getting stung by a bee in the middle of being swabbed), and that the ear in fact HAS wax to swab, before swabbing.

One preliminary unit test tells you that you're not holding a knife. The integration tests do almost everything else. You need to authenticate (ask first, maybe this alone tells you they have ears... OR NOT), connect to the network resource (reach your arm out with Q-tip in hand, and approach the ear), start the transaction (apply pressure to someone else's ear), complete the transaction (extract a sample of ear wax), and check the response for your request (inspect the earwax specimen). One last unit test to make sure you got back wax, and not blood.

Sounds disgusting, right? It is. And you can keep a rubber ear in the cabinet, as a stub test target, sure. We all understand the textbook definition of the noun (earwax, integers, money).

Real ears still need to be cleaned.

[WorldMaker]

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.

[pavement]

Come on, people. Work with me, work with me.

[unclewaltr]

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

[mcphage]

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

[zbentley]

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

[dingo_bat]

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

[aeorgnoieang]

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

[pavement]

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 of the project. A runaway batch process with an infinite loop of purchases is bad, infinite refunds is even worse.

Sometimes these tests are needed to ensure that the service account exists on the third party system, is recognized, and has limited permissions for a fixed, restricted set of API calls. The tests might be run only during a release deployment, against live production, but more frequently against a third party sandbox host while coding. This is a very common pattern.

[aeorgnoieang]

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

[taeric]

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.

[bglusman]

I have tests that do this :-) Well, not for an order, but with a sort-of-monolith sort-of-microservice system with email, dashboards, reporting, a JS SPA and a lambda/flask/zappa based API thats decoupled from the admin app, we want one live, round trip of all the data flowing and actions along the way... we can point it at staging, production, and I think dev (via docker-compose, but that part wasn't done last I worked on this). It relies on some special hard-coded/pre-setup accounts and stuff, but they're real, just marked as test related in their names so everyone knows not to touch them.

[jdbernard]

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.

[macca321]

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