mock

To fully show my hand: What I do not like are mocks which have you outline a series of behaviors/method calls which are expected to be called, typically with specific input parameters, often with methods in order. In python, this looks like setting up Mocks and then using `assert_called` methods. In Go, this means using Gomock-generated structs which have an EXPECT. A test should not fail when the outputs do not change. In pursuit of this ideal I often end up with fakes (to use Martin Fowler's terms) of varying levels of complexity, but not "mocks" as many folks refer to them. [0] - https://docs.python.org/3/library/unittest.mock.html#unittes... [1] - https://pkg.go.dev/github.com/golang/mock/gomock

AFAICT that uses go/types, loaded uniquely per execution via packages.Load¹, which is by far the primary reason why e.g. go.uber.org/mock (previously github.com/golang/mock) can become extremely slow. mockery v3 does not do this. it type-checks just once for ALL mocks, regardless of the number, so it essentially does not grow slower as you create more mocks (since type checking is usually FAR slower than producing the mock). 1: https://github.com/maxbrunsfeld/counterfeiter/blob/000b82ca1...