The .On().Return() syntax is certainly reminiscent of testing strategies in other languages (ruby/js) which, to me, is a big red flag: we're not writing those languages.

Agreed; that syntax doesn't sit really well with me because it doesn't feel like Go at all. Maybe we could continue shopping to find a more suitable mocking library.

The golang/mock syntax looks even worse to me:

  ctrl := gomock.NewController(t)
  defer ctrl.Finish()

  m := NewMockFoo(ctrl)

  // Does not make any assertions. Executes the anonymous functions and returns
  // its result when Bar is invoked with 99.
  m.
    EXPECT().
    Bar(gomock.Eq(99)).
    DoAndReturn(func(_ int) int {
      time.Sleep(1*time.Second)
      return 101
    }).
    AnyTimes()

I'll try to look into some others:

• https://github.com/maxbrunsfeld/counterfeiter

am extremely suspicious of mockery, however; in general I am an opponent of code generation as I have found it to cause more trouble than it saves in the long run.

I have also never even considered code generation coming from dynamic languages (except for if I would have to build a parser), but I can see the appeal in a statically typed language. For this particular purpose, the generated code is never used at runtime, and since the compiler enforces type safety anyway, I feel more confident checking generated code into version control.

Of course, nothing is forcing us to use code generators. However, it can be quite tedious and possibly error-prone to write stubbed implementations by hand.

I've looked into other mocking libraries for Go that I could find by searching:

• https://github.com/maxbrunsfeld/counterfeiter#using-test-doubles-in-your-tests - looks nice, author is a GitHub alumni
• https://github.com/matryer/moq#how-to-use-it - looks simple enough
• https://github.com/percolate/charlatan#example - simple enough
• https://github.com/petergtz/pegomock#generating-your-first-mock-and-using-it - uses BDD syntax 👎
• https://github.com/gojuno/minimock#setting-up-a-mock-using-whenthen-helpers - uses When/Then syntax 😕

They all seems to be primarily designed for generating code, i.e. to be used through go generate. Otherwise, setting any of these up per every mocked interface could be exhausting.

mislav to redo with one or two other libraries so we can compare and contrast

My thoughts now that we have experimented with multiple of these libraries:

• golang/mock - pros: full-featured. cons: verbose usage as it needs a controller
• testify + mockery - pros: we already use the library, full-featured. cons: every stub call goes through the same Do() method (making it tricky to trace calls using gopls features), tricky to match incoming arguments when the method accepts an interface
• counterfeiter - pros: every stub uniquely named by the method is stubs (e.g. DoThingsReturn() stubs DoThings()). cons: doesn't panic when a non-stubbed method is called, manual call count verification
• moq - pros: define stubs as funcs inline, super simple. cons: manual call count verification

I found myself gravitating to moq because of its simplicity of defining funcs, meaning that the library entirely avoids having to invent an API for matching incoming arguments or to define return values. The caller simply defines a func for every stubbed method. I think I would like us to explore this approach more, even if it means manually having to verify the call count for each method that we care that it's called only N times. I've pushed an exploration here: git-push-mocks...git-push-mocks-moq

Closing as this was a spike/investigation.