It's a cursed notion that unit-tests are "set up mocks around functions and call them with different arguments".

It's more useful to categorize tests by how hard to setup an environment. In reality cost/usefulness line lies on this boundary.

* in single process * multiple process using IPC * multiple processes using network * tests validate functions calling foreign services

I see many devs (including myself) call "integration" tests as "unit" tests because in your particular app/system they are easy to spawn locally even without any container.

While I tend to agree, the Go toolchain authors are very specific: it doesn’t count as unit test coverage when the code and the test are in different packages. And our management has no interest in breaking with them on this.

You are free to write tests that compose packages, and I’ll do it for my own sanity and confidence. But that’s in addition to, not instead of, the minimum “not horrifically irresponsible engineering” standard of universal, exhaustive, very detail oriented mock driven unit tests within all packages.