Skip to content
This repository was archived by the owner on Jun 27, 2023. It is now read-only.

genmock doesn't import self_package when interface use structure that have same package with interface #11

Closed
soulski opened this issue Sep 30, 2015 · 12 comments

Comments

@soulski
Copy link

soulski commented Sep 30, 2015

source code

type A struct {}

type I interface {
    Foo() A
}

Mock that was generate from genmock will have error because when genmock create mock file mock package is mock_* so mock won't find struct A in mock_* package

@petrkotek
Copy link

+1 (having the same issue)

@dsymonds
Copy link
Contributor

dsymonds commented Oct 6, 2015

How are you running genmock? If I add that example to sample/user.go and run update_mocks.sh, the generated code imports the sample package just fine.

@petrkotek
Copy link

Thanks @dsymonds for taking a look. I call mockgen via go generate like this:

...
//go:generate mockgen -source mappers.go -destination _mock_mapper/mock_mapper.go
...

and then e.g. go generate ./...

i can imagine that it's a bit tricky (or not possible) to reliably generate the import statement for mocked package when using the filename (like mockgen -source mappers. go -destination ...) instead of fully qualified package name (like ./update_mocks.sh does).

generating a mock this way works fine:

mockgen github.com/<organisation>/<repo>/mappers Mapper > _mock_mapper/mock_mapper.go

I'm not sure if that's a bug or expected behavior, but could be eventually handy to mention this as a caveat of using mockgen -source ... -destination ... syntax.

@dsymonds
Copy link
Contributor

dsymonds commented Oct 6, 2015

Source mode is pretty hard to get right, and gomock can't tell what A you necessary mean. That's why I generally recommend people use the reflect mode, since it avoids all these pitfalls.

@petrkotek
Copy link

Makes sense. I've updated my //go:generate to the form below & works as a charm. I'm pretty sure it will resolve @soulski's issue too.

//go:generate sh -c "mockgen github.com/<org>/<repo>/mappers Mapper > _mock_mapper/mock_mapper.go"

Thanks a lot, really appreciated.

@dsymonds
Copy link
Contributor

dsymonds commented Oct 6, 2015

You shouldn't have to use sh -c, but that's a separate issue.

@dsymonds dsymonds closed this as completed Oct 6, 2015
@petrkotek
Copy link

Reason for using sh -c is that I need to redirect output of mockgen <pkg> <interfaces> to a file (otherwise > and output_file.go are interpreted as another string arguments for mockgen.

@dsymonds
Copy link
Contributor

dsymonds commented Oct 6, 2015

Why not use the -destination flag?

@petrkotek
Copy link

Because mockgen <pkg> <interfaces> -destination _mock_mapper/mock_mapper.go results in Expected exactly two arguments error.

@dsymonds
Copy link
Contributor

dsymonds commented Oct 6, 2015

Flags have to go before non-flag args.

@petrkotek
Copy link

:facepalm: of course, sorry & thanks

@jmhodges
Copy link
Contributor

Could this be reopened? I'm trying to use the bazel build system and generating a mock from outside of a generated go protobuf library, and the bazel/rules_go stuff doesn't provide a working $GOPATH for me to throw mockgen at. That is, the reflect style won't work, and only -source would, but it seems to be broken.

Specifically, mockgen with -source and a -package that is different from the original package, generates code that references types as if they are in the original package and setting -self_package and -imports to anything just seems to cause a . to go in front of the type names but not the actual package.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants