[revskill]

To me, unit tests only make sense for pure code.

For impure code, it made no sense to make a unit test.

Ability to separate pure vs impure code determines your test suites, where should be put in unit test, where should be put in integration test.

[stagas]

It looks like you are coupling your unit tests with your integration tests. At integration level, we test if the integration paths work under various conditions, that is, only the code that deals whether our unit has been called correctly, with the right parameters, etc. At unit level, we mock all of the dependencies and test the branches of the effective code under various conditions. And at the acceptance level we should be testing our business logic requirements, to make sure all of our features are working the way they should, especially during refactoring (where integration and unit tests are subject to change).

[AstralStorm]

Not even close. Functionally pure code can be proven correct instead of tested. Or it can be tested exhaustively. It's the exact case where typical tests are worthless.

That is a small piece of actual software, everything everywhere works with IO or state like databases, each of which comes with ordering and concurrency assumptions. Every time you have a variable that is changed, you have more state to test.

Almost all code is impure.