[fesc]

What would "integration tests" (that you don't write) look then in your opinion?

I ask because in my team we also a long time made the destinction between unit/integration based on a stupid technicality in the framework we are using.

We stopped doing that and now we mostly write integration tests (which in reality we did for a long time).

Of course this all arguing over definitions and kind of stupid but I do agree with the definition of the parent commenter.

[atticora]

> What would "integration tests" (that you don't write) look then in your opinion?

In our local lingo, an integration test is one that also exercises the front-end, while hitting a fully functional back-end. So you could think of our "unit tests" as small back-end integration tests. If you think that way, we don't write very many pure unit tests, mostly just two flavors of integration tests. That works well for our shop. I'm not concerned about the impurity.

[ebiester]

The "impurity" isn't the problem. The problem is that such integration tests take a longer time to run and in aggregate, it takes minutes to run your test suite. This changes how often you run your tests and slows down your feedback loop.

That's why you separate them: not because the integration test isn't valuable, but because it takes longer.