Great points. I have to say that I agree with you. Very pragmatic approach. Units don’t have to be classes.

I disagree on that definition of a unit. I think it is important that those tests are called unit tests and not class tests. When a class can’t possibly work without a specific other class, is it still a unit? I guess the definition of the unit has to be done on a case-to-case basis.
Since unit tests are used in a certain way, they should have specific properties: they should run fast and should not depend on the platform or on I/O etc. That means they should not test too much code, iow, the code under test should a reasonably small portion. But not necessarily as small as possible, i.e. not a single class.
I know this is against the puristic and idealized view of theory, but it is a pragmatic view. If you know that the actual class you depend on does its job well (because you have it under unit tests) and don’t care about how often the dependent class actually calls which function of it, then there is no need to mock it away.
Imo the “units” we test should be small enough, but not smaller.

You are correct, a unit is something that we construct from the language, but doesn’t represent truly what a unit is logically in our code. The problem is that unit testing is based on a the language and the tools. We want to be able to test the smallest unit of code that is cohesive, which is usually a class.

Test code is as important as production code. It can have bugs. It needs to maintained. And we should strive to keep it as stable as possible.
Functional/Features tests document a large part of what you code is doing. By looking at these tests, one should be able to identify interaction and state changes going on in a particular scenario. I think the focus should be on improving the quality of the test code, rather than questioning the value of these tests.

Sorry for the slip-up with your name: (Jason -> John) Guess that’s what comes of seeing jsonmez, and having some familiarity with Javascript!