Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Suggestions for Duplicate Interface Names #96

Open
jpopadak opened this issue Nov 7, 2019 · 2 comments
Open

Suggestions for Duplicate Interface Names #96

jpopadak opened this issue Nov 7, 2019 · 2 comments

Comments

@jpopadak
Copy link
Contributor

jpopadak commented Nov 7, 2019

Do you have any suggestions for duplicate interface names?

For example, I have this type:

type StructUnderTest struct {
    firstClient first.Client
    secondClient second.Client
}
package first

type Client interface {
    Method()
}
package second

type Client interface {
   Method()
   AnotherMethod()
}

Both first.Client and second.Client are named the same.

As a result, when I try to create the mocks, I get two files, both with NewMockClient() in them. Is there anyway I can specify a way to override the function name? Like NewMockFirstClient() and NewMockSecondClient()?

I can change the package, but then I get issues with Go (and Linters) complaining there is more than one package in the same folder.

@jpopadak
Copy link
Contributor Author

jpopadak commented Nov 7, 2019

Thanks to a coworker, just found this option on pegomock generate:

--mock-name=MOCK-NAME Struct name of the generated mock; defaults to the interface prefixed with Mock

Should be sufficient enough for what I am trying to do. :) Might be useful to have an example of this as well in the README.

@petergtz
Copy link
Owner

petergtz commented Nov 7, 2019

@jpopadak Glad you found the way to solve it.

In general, I avoided documenting CLI options that are more or less obvious from the CLI help to avoid repeating the description. For such options, the README specifically says:

For more flags, run:

   pegomock --help

If you feel like this is still worth being documented explicitly, I'd be happy to merge a PR ;-).

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

No branches or pull requests

2 participants