I think the unit that you test with a unit test was always supposed to be something abstract. It is some logical unit of something that I want to test. It might or might not be conveniently confined to something more concrete like a specific file or function, but that is not important. And what was a function yesterday may be a class now and an entire module next month, even if logically it is still the same "unit".
When people try to decide what a unit is they often settle on things too small anyway, like methods in Java. This easily leads to mock-heavy, brittle, test-cases that makes too many assumptions about the code they test. Carefully scripting with mocks how you expect a single method to behave and then update those tests every time you make even minor changes to your code is not likely to catch many errors. In my experience that kind of unit testing at best is successful at telling you that you have to rewrite you tests. As long as a test runs fast and no i/o is triggered I am fine with calling it a unit test.
I prefer higher level tests when possible. I saw jecxjo had some good points about how that is not always possible. But in general I think time is better spent writing a few system-level tests and some integration tests to see that everything works as intended on a higher level, even if it does not always help you pinpoint exactly what is wrong when something breaks.
tags: #tests #software