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?
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
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?