> If it's a feature or integration test, why is it a problem to pull in the other packages?
The compiler does not allow the cyclic dependency (even if it's only caused by testing code).
And to pick a nit, to me, if there are several units of your system pulled in, it's arguably not a unit test. It's an integration test.
I don't love mocks, but I don't hate them either. They have their place as part of an overall testing pyramid.
To me, mocks are useful for one thing only: there is some expensive or flaky dependency of your code that you may have poor visibility into, and you want to write a test that does not rely on its availability. Mocks for databases, file systems, REST APIs, externally maintained libraries, etc. all make sense to me. But if some library is developed locally (or in the extreme case, by you) and you can easily depend on its existence and stability, then I see no reason not to write code that depends on that library and test against that library. This is a testing strategy for a pragmatist, not a purist.
Go in particular makes it easy to separate a single codebase into separate logical packages, and if you do so, it often makes sense to test them together. That's why this is a pretty Go-specific issue.
If it's a feature or integration test, why is it a problem to pull in the other packages?
If it's a unit test, why not mock out the other dependencies to focus on the narrow behaviour?
Go makes the latter both easier (implicit interface typing) and harder (lots of libraries only providing physical structs).
I have to admit I've grown nervous about tests that require you to crack open an object to inspect its internal state. I've often seen designs that "need" private variable inspection recomposed into a more functional style or broken into smaller, cooperating modules/objects.
Put another way: if the module's behaviour is so complex that you must inspect private state to assure behaviour, perhaps the module is too complex overall.
Of course YMMV, consult a doctor etc etc