Unit test – purist versus practical
Whenever you ask a question on unit testing in a forum there is always that one person whose only job is to point out that what you are doing is not unit testing but integration testing. It is important to know this difference but it is more important to not lose sight of the goal. Also, you need to adopt a terminology that works for you and your team rather than what purists think or say.
In absolute terms, if a test depends on anything that is not in your control, then it is not a unit test. For example, if a method that you are testing uses a public function or a function from an included library or a database or an external API, then it is not a unit test but an integration test. For a test to qualify as a unit test, you need to mock all these dependencies and get them under control, only then you can claim your test as unit test. Now that we have the purists happy, let us move to a more practical world view.
When a regular joe developer refers to a test as unit test, what she means is she is trying to test a functionality in a massive gnarly application that she thinks is a small independent unit. This unit might have some components that is not under her control. A regression test would test how these units behave when interconnected. Instead of debating whether what she is doing is unit testing, a better discussion in my opinion is trying to figure out what is the intention of the test and what needs to be controlled and not. Figuring this out and working on achieving this will add more value than debating whether something is a unit test or not.