How can I import mocks from one package into another?

[leepowelldev]

This might not be possible... I'm using a bare bones mockery config:

all: True
packages:
  local.dev/my-package:
    config:
      recursive: True

And a file structure of:

go.mod
main.go
package-a
  - mocks_test.go
  - a.go
  - a_test.go
package-b
  - mocks_test.go
  - b.go
  - b_test.go

My package-b consumes package-a and I'd like to be able to use the mocks from package-a in my package-b tests. I have tried generating mocks into a centralised mocks directory like so:

go.mod
main.go
mocks
  - mocks.go
package-a
  - a.go
  - a_test.go
package-b
  - b.go
  - b_test.go

But I end up get cyclical import errors during my imports with the mocks using the structs from the package being tested. I then tried moving those structs out into a separate types package - which solves the issue, but I don't like that the code isn't co-located:

go.mod
main.go
mocks
  - mocks.go
types
  - types.go
package-a
  - a.go
  - a_test.go
package-b
  - b.go
  - b_test.go

Is there an alternative approach I can use? Maybe either with the replace-types or packages? Sorry, fairly new to mockery, and Go in general. Any help here would be great.

[LandonTClipp]

What you're asking for is fundamentally not possible without restructuring your code. You can do any of:

1. Combine package-a and package-b into the same package.

2. Don't attempt to import the mocks of a separate package as you are doing. This would involve, for example, package-b defining its own interfaces and using the mocks generated from that interface instead of the mocks generated from package-a's interfaces. You can do something silly like:

   type PackageBIntf interface {
       packageA.PackageAIntf
   }

   This would cause mockery to treat it as a separate interface and generate a mock for it.

3. Generating multiple copies of the same mock: one in package-a and one in package-b by using the configs: parameter (see the Extended Example in https://vektra.github.io/mockery/latest-v3/configuration/#mockery-init). This would likely fix the circular import issue because the mocks would reference an external package but not vice versa. This is actually similar in spirit to option 2 but shifts the required boilerplate from Go code to YAML, so it's still not nice.

4. Change the package name of your _test.go files to be [package_name]_test. This is a fun little hack in go where test files can technically be considered part of a separate package from the code under test. You can imagine that if they are separate packages then it will fix circular import issues because package packageA will not be importing any mocks anywhere (why would it need to?), only the package packageA_test files would, and your mocks do not import the test packages. See https://pkg.go.dev/cmd/go@master#hdr-Test_packages for more details.

Which option would I recommend? 4 is probably the easiest. I do this for all of my test code for this exact reason. The caveat is that _test packages, technically being considered external packages, have no visibility into unexported types or attributes, although as a matter of good testing practice may be desired anyway (test your public-facing surface, not internal details). This may pose an issue if your tests are operating on internal details. In such a case, 2 is probably the next easiest solution.