I think that we should not treat unit as class, but as large class group as possible without mocks. Plus mocks supposed to be used for things that are outside of given process memory (like databases, 3rd party API calls). Sometimes when I see too many mocks it looks for me as we would test our mocks, instead of code
At the same time I don’t believe that we should blindly follow 100% of code coverage. As a result we can see test which tests if programming language works. Sometimes making tests testing line by line what our code does.
Creating many mocks makes refactoring harder, and having 1:1 test -> production relation doesn’t help.
In addition having 1:1 to test => production code relation can create so many test cases that they are will be slower than unit tests of groups of classes (ie Angular testing)
As a rule of thumb I prefer to write tests that can test as much production code as possible. So to have:
(lines of production code tested) / (lines of code test) ratio as high as possible.
And I call this test effectiveness ratio (TER).
Many mocks make refactoring harder
I do not like mocking, because extensive mocking leads to situation that with every change in code you need to change many mocks. Ideal situation for me is I can do refactor without touching tests (because I did not change behaviour)