Great write up. I laughed at this:
You should not mock someone else's class (a good life rule in general),
I generally prefer functional tests over unit tests with mocking and such. So many people flip out and say, “but, but, what if you database dies or something else breaks due to the combination of everything together?” Etc. In my experience that’s usually the kind of thing that happens in production and code with high unit test coverage can’t handle it, and the devs have little experience recovering from it. Functional tests (from request, all the way to the db and back again to response) seem to give me the most bang for the buck and can be really helpful when refactoring something internal to ensure it didn’t have some larger consequence.
The line between unit and functional test is much fuzzier than the purists would argue. Generally speaking, the more contained something is the more tests it should have.
If you're building a library (which is most of the PHP I've been writing lately), the emphasis should be on small-unit tests. If you're building an application that is mostly just stitching together other libraries (which most should be), then yes, you'll probably have mainly functional/end-to-end tests. That's because the lower level tests are already written for you by the library author (who may be you, or not).
My current project is Tukio, a reference implementation of the in-progress PSR-14 standard for PHP. (That's where the examples in the article came from.) There's by design no external resources to think about (DB, etc.), so everything I'm doing is basically just feeding it data, where the data is sometimes a callable or class instance. So... I just make callables and class instances, kthxbye.
If you're making a library that uses a network connection, mocking that in your tests is crucial because you don't want to introduce the 500 extra variables of a network connection into your tests. You want to simulate the collection of variables you care about and test those. (Fake a 200 response, fake a timeout, etc.)
I am also, on the side, working on a simple photo gallery in Symfony 4. I'll be honest... it has no tests at all at the moment. That's because it's maybe 20 lines of code, plus templates, plus a bunch of external libraries. There's barely anything there to test, and I'm mostly just fiddling with it to see what happens at this point. At some point I'll probably put some functional tests around it, on principle, but at this point the fake image data I'd have to generate for it and the tooling to support it is not worth it. The libraries I'm using are all from Symfony and the PHP League, though, so I'm confident they're all very well tested. (Haven't hit a bug yet.)
As I've said elsewhere, best practices are contextual.