My philosophy is slightly different: Unit tests should test one API. But whenever possible, they should respect the encapsulation of that API, and only test the public access points.

In particular, I dislike unit tests which dig around in the private implementation details of a module, and specify how it connects to other modules "behind" it. Invasive unit tests make it much harder to change those implementation details.

You're not really talking about unit tests, then: you're talking about progressive integration tests, since the failure of a module "behind" your module can cause extra spurious failures.

Now, it may in fact be the case that you may argue that you can replace unit tests with all of these sorts of integration tests. I'm not so sure: digging around the private implementation details ways usually the easiest way to test strange error conditions—but it’s by no means easy. Though these days, I try to write as much pure code as possible, nullifying the benefits of an approach like that.

That's a good point. It's generally considered to be bad form to lock down the internals too much. It makes refactoring harder.

In general, when testing a class I obey the spirit of 'testing 1 thing' by writing tests that gradually increase in scope, so the first tests are testing 1 thing, the next tests are testing 2 (1 of which was already tested) etc.