3 ms·

I think it's actually quite simple to come to a common language for unit and integration tests if you start from "integration" instead: if there is any sort of

I think it's actually quite simple to come to a common language for unit and integration tests if you start from "integration" instead: if there is any sort of integration (two things interacting: your test setup can tell you that's happening), it's an integration test. If there are no integrations, it's a unit test. As in, it's all in the name. How does one fit a whole "service" (if we are talking something like a networking service like web API server there and not a DDD-style service) there really beats me, but I am happy to hear you out. I'd note that things like setting up a client and then configuring it to access a service already fails that test, even if you hide that complexity into fixtures or "external" test setup. Edit: for avoidance of any doubt, these are terms without clear, widely accepted definitions. I am mostly sharing how I am making what I think is a useful distinction to drive me to write properly scoped tests and structured code.

Ma8ee 3y ago
> if there is any sort of integration (two things interacting: your test setup can tell you that's happening), it's an integration test. Two things of what? There are people that claim that as soon as there are more than one method involved, it's an integration test, and more common, that as soon as there are more than one class involved, it is. This lead to absurd mocking of utility classes to make sure that only one thing is tested at the time. And then, of course, the tests become very fragile. And while there are situations when it is useful to only test one specific thing, what we really care about is the behaviour of whole system of many parts. We mock (fake or stub) to make the tests faster, repeatable and reliable. That is, what we don't want in our tests are slow calls, over slow networks or lengthy calculations. We want the calls to be repeatable, so we don't want to call, say, a database where the state changes between test runs. And we don't want to make calls to unreliable services; unreliable because they are under development or because they are over an unreliable network.
- necovek 3y ago
  I would be in the camp that says two methods calling each other are an integration, but I avoid mocking as much as possible. But if you need to use mocking there heavily, your code is not structured well: look for functional style and acyclic directed graph structure of calls.

Ma8ee 3y ago

> if there is any sort of integration (two things interacting: your test setup can tell you that's happening), it's an integration test. Two things of what? There are people that claim that as soon as there are more than one method involved, it's an integration test, and more common, that as soon as there are more than one class involved, it is. This lead to absurd mocking of utility classes to make sure that only one thing is tested at the time. And then, of course, the tests become very fragile. And while there are situations when it is useful to only test one specific thing, what we really care about is the behaviour of whole system of many parts. We mock (fake or stub) to make the tests faster, repeatable and reliable. That is, what we don't want in our tests are slow calls, over slow networks or lengthy calculations. We want the calls to be repeatable, so we don't want to call, say, a database where the state changes between test runs. And we don't want to make calls to unreliable services; unreliable because they are under development or because they are over an unreliable network.

necovek 3y ago
I would be in the camp that says two methods calling each other are an integration, but I avoid mocking as much as possible. But if you need to use mocking there heavily, your code is not structured well: look for functional style and acyclic directed graph structure of calls.