Requested feature

Mockgen should support generating mocks for interfaces with generics.

Why the feature is needed The Go 1.18 is planned to be released soon, and I noticed that the mockgen tool doesn't support the generic. When a type parameter is in the interface, mockgen will throw an error.

Code example: https://go.dev/play/p/g1G2OvZPQpT?v=gotip

> go run github.com/golang/mock/mockgen -source=generic_mock.go
2022/02/13 10:59:41 Loading input failed: don't know how to mock method of type *ast.IndexExpr
exit status 1

(Optional) Proposed solution

1. In the code example above, the StudentRepository interface is concrete, so the gererated mock should be concrete too with the type parameters substituted.
2. The BaseRepository interface is abstract, so the generated mock struct should also have the same type parameters.

(My use case only needs 1, which mockery supports as of today.)

• Generate temporary program in current directory tree to pick up vendored dependencies during build
• Clean up the return of PkgPath according to the advice of rsc here https://github.com/golang/go/issues/12019#issuecomment-148747953

This fixes #4

The files I used to manually test this are here: https://gist.github.com/rgarcia/cf553169c4832543a0a9

I'm trying to generate a mock from a source.

$ cat x.go
package test

type X struct{}

type S interface {
	F(X)
}

$ mockgen -source x.go
// Automatically generated by MockGen. DO NOT EDIT!
// Source: x.go

package mock_test

import (
	gomock "github.com/golang/mock/gomock"
)

// Mock of S interface
type MockS struct {
	ctrl     *gomock.Controller
	recorder *_MockSRecorder
}

// Recorder for MockS (not exported)
type _MockSRecorder struct {
	mock *MockS
}

func NewMockS(ctrl *gomock.Controller) *MockS {
	mock := &MockS{ctrl: ctrl}
	mock.recorder = &_MockSRecorder{mock}
	return mock
}

func (_m *MockS) EXPECT() *_MockSRecorder {
	return _m.recorder
}

func (_m *MockS) F(_param0 X) {
	_m.ctrl.Call(_m, "F", _param0)
}

func (_mr *_MockSRecorder) F(arg0 interface{}) *gomock.Call {
	return _mr.mock.ctrl.RecordCall(_mr.mock, "F", arg0)
}

The generated mock does not import the original source for the type X. Should I edit the generated mock? I tried some flags like -imports, but it didn't work.

Thanks,

"self" import is generates as x ".". It works in gopath and with reflection based mockgen. Using -self_package does not affect the output.

Sample program (foo.go):

package foo

type Arg struct {}

type Foo interface {
	Bar(a Arg) error
}

Used command: $ mockgen -source=foo.go

Generated output:

// Code generated by MockGen. DO NOT EDIT.
// Source: foo.go

// Package mock_foo is a generated GoMock package.
package mock_foo

import (
	x "."
	gomock "github.com/golang/mock/gomock"
	reflect "reflect"
)

// MockFoo is a mock of Foo interface
type MockFoo struct {
	ctrl     *gomock.Controller
	recorder *MockFooMockRecorder
}

// MockFooMockRecorder is the mock recorder for MockFoo
type MockFooMockRecorder struct {
	mock *MockFoo
}

// NewMockFoo creates a new mock instance
func NewMockFoo(ctrl *gomock.Controller) *MockFoo {
	mock := &MockFoo{ctrl: ctrl}
	mock.recorder = &MockFooMockRecorder{mock}
	return mock
}

// EXPECT returns an object that allows the caller to indicate expected use
func (m *MockFoo) EXPECT() *MockFooMockRecorder {
	return m.recorder
}

// Bar mocks base method
func (m *MockFoo) Bar(a x.Arg) error {
	ret := m.ctrl.Call(m, "Bar", a)
	ret0, _ := ret[0].(error)
	return ret0
}

// Bar indicates an expected call of Bar
func (mr *MockFooMockRecorder) Bar(a interface{}) *gomock.Call {
	return mr.mock.ctrl.RecordCallWithMethodType(mr.mock, "Bar", reflect.TypeOf((*MockFoo)(nil).Bar), a)
}

Versions: go version go1.11.2 darwin/amd64 mockgen latest version

Is there way do return value depend on the input? I want to do something like the following pseudo-code var response string mock.EXPECT().SomeMethod(gomock.Any()).AnyTimes().Do(func(input string) { response = input + input }).Return(response)

I got deep into the code, and it look like it unsupported, I there other way to do it?

We run gomock/mockgen inside of a docker container. Previously that docker container was based on golang 1.12, but we upgrade it to 1.13 today. After upgrading to golang 1.13, mockgen started failing out:

mockgen --package=mock_seeds --destination=/go/src/github.com/xxx/yyy/mock_seeds/mock_seeds.go github.com/xxx/yyy/seeds ExternalAPIClient,ExternalAPIServer                                        
go: github.com/xxx/[email protected]: invalid version: git fetch -f https://github.com/xxx/zzz refs/heads/*:refs/heads/* refs/tags/*:refs/tags/* in /go/pkg/mod/cache/vcs/595ef178a 519bba79a7580920dc80e819bacb31e39f9842a1de283c683f92cd1: exit status 128:
     fatal: could not read Username for 'https://github.com': terminal prompts disabled

Our project has several golang modules it depends on that are private, with the obfuscated https://github.com/xxx/zzz being one of them. We use go mod vendor to commit them to the repo.

Why is mockgen running go get or git fetch or anything like that?

mockgen shouldn't be getting my source files, when they are all right there already.

What is going on, and how to solve it?

Resolves Issue: #262

• added ArgumentCaptor struct that composes Matcher
• added constructors for ArgumentCaptor
• included unit tests for ArgumentCaptor methods

The Captor() method takes a Matcher interface to make it as flexible as possible. AnyCaptor() is just there because it seems like the anyMatcher is probably going to be used with captors the most.

Description Partially fixing #419

It turn out there are two places calling go list:

• createPackageMap
• parsePackageImport, which calls packages.Load, which calls go list by default.

This PR avoids calling packages.Load and saves one of the go list calls. Some performance data:

With 0b87a54da2167cf3446363bb4b00c6de7677ceaa:

$ go clean --cache --modcache && time go run ./mockgen -source /Users/zplin/gocode/src/github.com/bazelbuild/bazel-gazelle/language/lang.go > /dev/null
go: downloading golang.org/x/tools v0.0.0-20190425150028-36563e24a262
go: extracting golang.org/x/tools v0.0.0-20190425150028-36563e24a262
go: finding golang.org/x/tools v0.0.0-20190425150028-36563e24a262
go run ./mockgen -source  > /dev/null  6.98s user 6.10s system 121% cpu 10.767 total

After this PR:

$ go clean --cache --modcache && time go run ./mockgen -source /Users/zplin/gocode/src/github.com/bazelbuild/bazel-gazelle/language/lang.go > /dev/null
go: downloading golang.org/x/mod v0.2.0
go: extracting golang.org/x/mod v0.2.0
go: downloading golang.org/x/xerrors v0.0.0-20191011141410-1b5146add898
go: extracting golang.org/x/xerrors v0.0.0-20191011141410-1b5146add898
go: finding golang.org/x/mod v0.2.0
go: finding golang.org/x/xerrors v0.0.0-20191011141410-1b5146add898
go run ./mockgen -source  > /dev/null  3.77s user 3.81s system 118% cpu 6.383 total

Submitter Checklist

These are the criteria that every PR should meet, please check them off as you review them:

• [ ] Includes tests

Reviewer Notes

• [ ] The code flow looks good.
• [ ] Tests added.

When using -source=interface.go the package that interface.go belongs to gets compiled/parsed before the mock is generated.

This is a problem if the tests that uses this mock also resides in the same package, as NewMockInterface won't exists.

This used to work on older versions.

Requested feature:

• Ability to check whether all expectations are met Currently, We only have EXPECT() which we can use in the user code and the rest (i.e. checking whether all expected calls were made) happens inside the controller. I would like to propose a utility which allows user code to check whether all expectations are met or not. A feature similar to the one which go-sqlmock provides, namely ExpectationsWereMet
• Resetting the mock behavior so that any previous behavior in not propagated to other tests Currently, We need to redefine the controller to define the new mock behavior. I would like to propose a utility which allows user code to reset all previous expectations so that test separation is maintained and dirty state of other tests is not propagated to other tests.

Why the feature is needed Right now, In my current project, While doing component-level testing, I need to inject the mocked dependencies of other services when my component gets initialized. So the controller is also defined there only. All these dependencies gets called in the code. It's time and resource consuming to initialize the application on each and every test. So if the above features are added then it would really help.

file: ct_main_test.go // This defines the TestMain.go and initializes the application

var remoteService

func TestMain(m *testing.M) {
    // initialize application
    ctrl := controller.NewController(helper)
    remoteService = mock.MockedRemote(ctrl)
    service = initializeMyService(remoteService)    
    .
    .
    os.Exit(m.Run())
}

file: ct_some_file_test.go

func Test_xxx(t *testing.T) {
      // Before proceeding, Reset any previous expectations
      remoteservice.ResetExpectations()

      // Given
      remoteService.Expect().ServiceMethod().Times(2)

     // When an API is called
     myService.SayHello()

     // Then
     remoteService.ExpectationsWereMet()    // Assert that all expectations were met. If expectations were not met, we throw an error
}

This would really help in implementing best practices in my current project and will help in avoid passing the dirty state between tests mistakenly.

PS: Excuse me if it's possible somehow using the current features provided by gomock. In that case, Let me know how can I achieve the same. Thanks!

Description

This partially addresses two issues related to how the source-mode parser handles embedded interfaces from other packages. Each is addressed in their own commit, but I've submitted this as a single PR since it is modifying very similar code. The problems this addresses are:

Incorrect generation caused by packages with the same name

When an interface embeds other interfaces that happen to refer to packages with the same name, we would previously generate incorrect mocks. For example, given following code:

// source
import (
    "some.org/package/foo"
    "some.org/package/bar"
)

type Source interface {
    foo.Foo
    bar.Bar
}

// some.org/package/foo
package foo

import "some.org/package/foo/internal/bar"

type Foreign interface {
    bar.InternalBar
}

// some.org/package/bar

type Bar interface {
    TopLevelBarMethod() string
}

// some.org/package/foo/internal/bar

type Bar interface {
    InternalBarMethod() string
}

the resulting mock would have two generated implementations of TopLevelBarMethod() and no copies of InternalBarMethod(). This was because all interfaces were merged into a single map keyed by the package name.

We solve this by creating a tree of fileParser objects rather than merging all imports and interfaces into a single set of maps. This helps ensure that transitive imports from the source file's dependencies don't erroneously conflict with any top-level imports.

Fatal Error on duplicate imports

Previously, it was possible to get the following error:

2020/02/24 10:22:25 imported package collision: "log" imported twice

From a multi-file package that happens to import two packages named "log." While the package itself is valid, the parser can't currently handle this case because it merges all imports into a single map. Fully fixing this issue will likely require larger changes. Here, we cover what I think will be many of the common cases of hitting this error by deferring the error until the ambiguous package name is actually referenced. This is enough to handle the following common case which currently results in this error:

package service

import "google.golang.org/grpc"

type Test interface {
        grpc.ClientStream
}

Partially fixes #156 _

Submitter Checklist

These are the criteria that every PR should meet, please check them off as you review them:

• [x] Includes tests: I've added a new integration-style test in mockgen/internal/tests/import_embedded_interface/

Reviewer Notes

• [ ] The code flow looks good.
• [ ] Tests added.

Release Notes

- Improved handling of embedded interfaces in source-mode parser.

Requested feature If a test makes an unexpected use of a mocked function, the call should result in a stack trace to fasten reaction to that error and help to detect if the code or the test is broken.

Why the feature is needed Improve usability and development speed. This impacts only the failing case which should only happen during development of a change. Thus, it does not affect retests of unchanged things and will equally not impact execution performance of test pipelines on successful runs.

(Optional) Proposed solution https://github.com/golang/mock/pull/680

H High severity golang.org/x/crypto Improper Signature Verification VULNERABILITY CWE-347 CVE-2020-9283 CVSS 8.6 HIGH SNYK-GOLANG-GOLANGORGXCRYPTOSSH-551923 SCORE 601 Introduced through github.com/golang/[email protected], github.com/gosnmp/[email protected] and others Fixed in golang.org/x/[email protected] Exploit maturity MATURE Show less detail Detailed paths Introduced through: github.com/golang/[email protected] › golang.org/x/[email protected] › golang.org/x/[email protected] github.com/golang/[email protected] › golang.org/x/[email protected] › golang.org/x/[email protected] › golang.org/x/[email protected] › golang.org/x/[email protected] github.com/golang/[email protected] › golang.org/x/[email protected] › golang.org/x/[email protected] › golang.org/x/[email protected] › golang.org/x/[email protected] Some more

This is an initial implementation of the proposal outlined in this issue, Proposal: Provide an option where every invocation of EXPECT() of a mock should override any previous invocations. #685

Hi team,

The proposal here is to allow for an option to bring GoMock closer in line with other mocking libraries that exist for other languages. In particular, the GoMock behavior of ordering mock expectations in a FIFO manner makes it difficult to bundle default mock expectations into a helper or testify Suite's BeforeTest block.

The problem

For example, the following set up won't work:

type ExampleTestSuite struct {
    suite.Suite

	repoAMock *MockRepositoryA
	repoBMock *MockRepositoryB
	repoCMock *MockRepositoryC

	sut *Controller
}

func TestExampleTestSuite(t *testing.T) {
    suite.Run(t, new(ExampleTestSuite))
}

func (s *ExampleTestSuite) SetupTest() {
	ctrl := gomock.NewController(s.T())
	s.repoAMock = NewMockRepositoryA(ctrl)
	s.repoBMock = NewMockRepositoryB(ctrl)
	s.repoCMock = NewMockRepositoryC(ctrl)

	s.sut = NewController(s.repoAMock, s.repoBMock, s.repoCMock) // subject under test

	// set up mock defaults
	s.repoAMock.EXPECT().Get(gomock.Any()).Return("foo", nil)
	s.repoBMock.EXPECT().Get(gomock.Any()).Return("bar", nil)
	s.repoCMock.EXPECT().Get(gomock.Any()).Return("baz", nil)
}


func (s * ExampleTestSuite) TestGather_HappyPath() {
	res, rr := s.sut.Gather()
	s.Require().Equal("foo, bar, baz", res)
	s.Require().NoError(err)
}

func (s *ExampleTestSuite) TestGather_RepoAFails() {
	s.repoAMock.EXPECT().Get(gomock.Any()).Return("", assert.AnError)

	_, err := s.sut.Gather()
	s.Require().Error(err)
}

func (s *ExampleTestSuite) TestGather_RepoBFails() {
	s.repoBMock.EXPECT().Get(gomock.Any()).Return("", assert.AnError)

	_, err := s.sut.Gather()
	s.Require().Error(err)
}

func (s *ExampleTestSuite) TestGather_RepoCFails() {
	s.repoCMock.EXPECT().Get(gomock.Any()).Return("", assert.AnError)

	_, err := s.sut.Gather()
	s.Require().Error(err)
}

Instead, one must do something like this:

type ExampleTestSuite struct {
    suite.Suite

	repoAMock *MockRepositoryA
	repoBMock *MockRepositoryB
	repoCMock *MockRepositoryC

	sut *Controller
}

func TestExampleTestSuite(t *testing.T) {
    suite.Run(t, new(ExampleTestSuite))
}

func (s *ExampleTestSuite) SetupTest() {
	ctrl := gomock.NewController(s.T())
	s.repoAMock = NewMockRepositoryA(ctrl)
	s.repoBMock = NewMockRepositoryB(ctrl)
	s.repoCMock = NewMockRepositoryC(ctrl)

	s.sut = NewController(s.repoAMock, s.repoBMock, s.repoCMock) // subject under test
}


func (s *ExampleTestSuite) TestGather_HappyPath() {
	s.repoAMock.EXPECT().Get(gomock.Any()).Return("foo", nil)
	s.repoBMock.EXPECT().Get(gomock.Any()).Return("bar", nil)
	s.repoCMock.EXPECT().Get(gomock.Any()).Return("baz", nil)

	res, err := s.sut.Gather()
	s.Require().Equal("foo, bar, baz", res)
	s.Require().NoError(err)
}

func (s *ExampleTestSuite) TestGather_RepoAFails() {
	s.repoAMock.EXPECT().Get(gomock.Any()).Return("", assert.AnError)
	s.repoBMock.EXPECT().Get(gomock.Any()).Return("bar", nil)
	s.repoCMock.EXPECT().Get(gomock.Any()).Return("baz", nil)

	_, err := s.sut.Gather()
	s.Require().Error(err)
}

func (s *ExampleTestSuite) TestGather_RepoBFails() {
	s.repoAMock.EXPECT().Get(gomock.Any()).Return("foo", nil)
	s.repoBMock.EXPECT().Get(gomock.Any()).Return("", assert.AnError)
	s.repoCMock.EXPECT().Get(gomock.Any()).Return("baz", nil)

	_, err := s.sut.Gather()
	s.Require().Error(err)
}

func (s *ExampleTestSuite) TestGather_RepoCFails() {
	s.repoAMock.EXPECT().Get(gomock.Any()).Return("foo", nil)
	s.repoBMock.EXPECT().Get(gomock.Any()).Return("bar", nil)
	s.repoCMock.EXPECT().Get(gomock.Any()).Return("", assert.AnError)

	_, err := s.sut.Gather()
	s.Require().Error(err)
}

It's not hard to imagine that the test body can really blow up once the number of dependencies one needs to mock out grows in size.

Examples from other languages

Some popular mocking frameworks in other languages support setting default mock behaviors, which helps clean up the test code:

1. gMock for C++ - "newer rules override older ones."
2. Mockito for Java - "Stubbing can be overridden: for example common stubbing can go to fixture setup but the test methods can override it."
3. Jasmine for Javascript

beforeEach(function() {
		this.propertySpy = spyOnProperty(someObject, "myValue", "get").and.returnValue(1);
	});

	it("lets you change the spy strategy later", function() {
		this.propertySpy.and.returnValue(3);
		expect(someObject.myValue).toEqual(3);
	});

4. Rspec for Ruby

    describe '#active?' do
    	let(:envrc) { '/Users/pivotal/workspace/loggregator/.envrc' }

    	before do
      	allow(FileTest).to receive(:exist?).and_return(false)
    	end

    it 'returns true when .envrc contains GOPATH' do
      allow(FileTest).to receive(:exist?).with(envrc).and_return(true)
      allow(IO).to receive(:read).with(Pathname(envrc)).and_return('export GOPATH=/foo/bar')
      expect(subject.active?).to eq(true)
    end

Proposal

Provide an option where every invocation of EXPECT() of a mock should override any previous invocations.

How to address returning different values based on input?

Use DoAndReturn to handle different args

Example Pull Request

https://github.com/golang/mock/pull/686

Alternatives Considered

There have been several previous issues filed that proposed a reverse ordering strategy for mock expectations:

• proposal: change order expectations are evaluated #246
• proposoal: NewController() should take options #238
• Default expectations and override #137

However, a couple usability problems arise with a reverse ordering strategy. One is that if one were to put a mock expectation in a SetupTest that runs before each test, it's implied that one must append AnyTimes() to the end of it. This is because if one were to leave that out, the gomock controller would continue to wait for for that expectation, even if one were to "override" it within the test block.

Actual behavior A clear and concise description of what the bug is.

Expected behavior A clear and concise description of what you expected to happen.

To Reproduce Steps to reproduce the behavior

1. ...
2. ...

Additional Information

• gomock mode (reflect or source):
• gomock version or git ref:
• golang version:

Triage Notes for the Maintainers

This proposal is to add an option -embed into mockgen.

Why: Sometimes we need to embed the source's interface (or structure) into a mock.

For example, a grpc server takes a mocked server implementation as an argument and determines if the interface is actually embedded as follows:

if !st.Implements(ht) {
	logger.Fatalf("grpc: Server.RegisterService found the handler of type %v that does not satisfy %v", st, ht)
}

https://github.com/grpc/grpc-go/blob/56ac86fa0f3940cb79946ce2c6e56f7ee7ecae84/server.go#L671

The following sample will result in an error when executed. https://github.com/stoikheia/GomockProposalSample1/blob/517c5bb860be39c9d2fa4faff6b0542fe29a7f3e/server/server_test.go#L26-L36

I think that -embed like option is necessary from above.