[radub]

The relevant tests fall somewhere between unit tests and integration tests. Many are intended as unit tests, but we prefer to test them on top of the "real" implementations of the layers underneath (instead of mocks) so they are integration tests as well.

> 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).

[jacques_chester]

It's been a while since I touched golang, so I don't recall the nitty-gritty of the cyclic problem.

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.

[sirclueless]

I write a lot of these tests in my code as well. They are not exactly unit tests, because they test code at multiple levels of abstraction at once, but they are written in exactly the same way as a unit test and are intended for the same purpose: to make sure that some unit of your code functions as it should and does not stop functioning.

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.