Direction of mockery: absorb different styles of mocks into this project

[LandonTClipp]

Background

There have been a lot of blog posts and discussions in online forums about the merits of using mocks vs other approaches like stubs (where you only return static values), spies (replacing only some of the methods), or even alternatives to mockery like https://github.com/matryer/moq. matryer/moq has gained traction due to its simplicity: methods are explicitly provided by the user, which reduces the need for complicated argument matching.

The mock objects created by mockery can be used to create expectations that behave like stubs by simply returning static values regardless of the arguments. You can also emulate moq's behavior by using the .RunAndReturn method in the .EXPECT() structs: https://vektra.github.io/mockery/v2.31/features/#expecter-structs. However, the criticism that can be made is that the usage of mocks gives you the tools that you can use to shoot yourself in the foot. For example, asserting the exact number of times a specific type of call is made, or the argument values which are passed to it, leads to flaky and fragile tests. It can be argued that good tests will never assert such things, so what is the point in having such tools?

All of the current alternatives to mockery suffer from performance issues at scale due to the way in which packages.Load is called. The introduction of the packages feature fixes this shortcoming and to my knowledge mockery is the only auto-mock generator to use this scheme. That's why I feel that absorbing the methodologies like what moq uses into the purview of mockery can be beneficial, not only from a performance standpoint, but from a configuration and coherency standpoint.

Discussion Prompt

Would it be useful to you if mockery provided function-attribute-style of mocks like what moq uses? This could be an additional configuration flag, like:

packages:
  github.com/vektra/mockery:
    interfaces:
      Foo:
        config:
          type: expectations # generate the current style of mocks for more expressive expectations
      Bar:
        config:
          type: method-attributes # generate moq-style mocks with methods as struct attributes
      Baz:
        config:
          type: future-idea # we can put any kind of strategy here

Benefits to the community

1. mockery would be able to support multiple different styles of mock implementations
2. Any style of mock can leverage mockery's expressive configuration semantics, something that is lacking in all other mock-generation projects.
3. Your codebase won't have to be split amongst different projects
4. The current Go community's "zeitgeist" around mocks can always be described by just adding a new generator to this project and selectively switching it on via config.
5. Stretch goal: mock implementations could be defined externally in a Jinja template, so any arbitrary design can be passed to mockery through a jinja text file. The variables you'd need to populate the jinja template would be provided for you. This means you can let mockery do the heavy lifting of parsing packages and simply tell it what you want your template to look like. (this is kind of a crazy idea but the imagination runs wild sometimes)

Tell me your thoughts!

[LandonTClipp]

Here's one possible implementation:

https://go.dev/play/p/4vQ_Eooini9

type Getter interface {
	Get(s string) string
}

func GetFromDB(s string, g Getter) string {
	return g.Get(s)
}

// stubs to be generated from Getter
type GetterStubs struct {
	Get func(string) string
}

type StubGetter struct {
	Stubs GetterStubs
}

func (s StubGetter) Get(value string) string {
	if s.Stubs.Get == nil {
		panic("Get was not set")
	}
	return s.Stubs.Get(value)
}

// test method for GetFromDB
func TestGetFromDB(t* testing.T) {
	stubGetter := StubGetter{
		Stubs: GetterStubs{
			Get: func(s string) string {
				return s + " bar"
			},
		},
	}

	value := GetFromDB("foo", stubGetter)
	if value != "foo bar" {
		t.FailNow()
	}
}

This could be considered a bare-bones stubbing implementation that does no call assertions and records nothing. This is the simplest kind of test double. This proposal differs from matryer/mock in that the stub methods are in a separate Stubs struct, instead of being part of StubGetter. This prevents possible (but practically unlikely) naming collisions.

The config to generate this would be:

packages:
  github.com/vektra/mockery/v2/pkg/fixtures:
    interfaces:
      Getter:
        config:
          type: stub