This should be an easy question to answer, right? Turns out that there are several definitions of unit testing, and even though they are similar, t...
For further actions, you may consider blocking this person and/or reporting abuse
Your last point is interesting: people write integration tests when they encounter code that has side effects and they want to have the side effects tested. Another common strategy is to use mocks (preferably generated ones) via e.g. Mockito in Java. This is a great way to test code paths where the side effect is the most interesting thing that happens in a unit tests without making it an integration test.
Unfortunately, lots of developers don't appreciate the futility of doing code coverage tests with integration tests. The whole point of a unit test is that the units are small and there is a small and finite number of paths to test so you can achieve a high degree of test coverage with little effort. This is not true for an integration test. The more stuff you gobble together the more code paths you have and it quickly explodes beyond the threshold of having reasonable coverage.
It is for that reason that I prefer to write either an end to end, blackbox integration test that is about testing realistic user scenarios against something that closely resembles the shipped product configuration, or a pure unit test that is about covering all relevant code paths. Anything in between neither achieves the goals of coverage nor of realism and tends to be a waste of time and resources.
If you are mocking half your system and then running some in memory database, your tests are not very realistic and your code coverage is likely to be poor. So, why would you do that exactly?
My personal experience is that this kind of tests become more of a burden than benefit in a long run. I should know, I've written thousands of tests like in this post. The number one reason why I want tests is safety when refactoring the solution. However, tests with too small unit don't support this. It' rare that refactoring happens in such a limited scope and therefore tests need to be modified simultaniously with production code, which scares me.
Nowadays I write unit tests with larger scope and I recommend giving it a try!
For further reading: taimila.com/blog/unit-of-unit-test...
I think unit tests are not always appropriate. If you're trying to test code which is largely business logic I'd go with unit testing, for example. If you're trying to test code which is very network intensive I would do integration testing or something along those lines instead. You end up doing so much mocking in those situations that it becomes apparent that you're making a lot of assumptions (i.e., the benefit is negligible).
Pick the right tool for the job I suppose.
To keep it simple to explain I tend to say that unit tests should be the smallest piece of code possible (like a function) and should not do any IO. To me these are the most important aspects of unit testing.
Thanks for making it clearer.