Clojurians Log v2

Sometimes you specifically want to test against real, live services in integration testing. Some services offer a "sandbox" version of their API for this sort of testing. Services that don't have that can be more challenging. But if you don't do any (automated) testing against the real service, then you're going to end up running into production-only weirdness at some point.

That said, you don't want to be calling those services in unit tests...

Right, agreed that you may want to run tests against the real thing. Perhaps the misunderstanding is that there could be a integration tests that run in every commit (light ones) and a bigger integration / functional suite that runs before deploys or nightly. Main concern is that it could make the suite unstable, fails because the service is down, but our code is good.

Yeah, I think I'd separate out those tests in its own suite. If the regular suite is too slow or too flaky, people will just stop running the tests, morale will plummet and productivity stops.

Contract testing might be an option for you: https://www.youtube.com/watch?v=dvHASrrQSzg

> Main concern is that it could make the suite unstable, fails because the service is down, but our code is good. Then the integration test should account for the service being down -- because that's a real thing that could happen in production. I agree that the tests you run regularly, locally, need to be fast so that might be a gating factor on whether you include "slow" tests by default (regardless of unit/integration). Most test runners have ways to tag tests so you can choose whether to run them or not.

Or, you can use vcr-clj or something similar to make a call, then cache the result 🙂