Design Proposal: integration of `github.com/matryer/moq`-style mocks about mockery HOT 2 CLOSED

Hi @LandonTClipp
Thanks for the proposal and the solid preparation work. I am not yet familiar with the ins and outs of mockery, so I am not yet able to comment on all the aspects of the proposal. But still let me share some thoughts:

It doesn't make it impossible to do nasty things like call count and argument value assertions, but it makes it somewhat harder to do.

As a experienced user of moq, I do not agree with this observation. Count assertions are extremely simple, e.g. len(mockedPersonStore.CreateCalls()) for the mock in the proposal. For argument assertions, it is my observation, that the impact of the arguments on the test result is in most cases less important than the result, that is returned from the mock. That being said, if a mock is just called once (per test execution) again, it is straight forward to have the necessary assertions in the function body of the mocked function. The big advantage in this case of moq is, that the assertions look the same as all the other assertions (in contrast to the clumsy for, that is required by testify with EXPECT().
Maybe the most "challenging" thing for most users that work with moq generated mocks are the proper handling of multiple calls to the same mock in a single test case. For this, the approach with queues served us well (see matryer/moq#187 (comment), unfortunately, this tip did not yet make it into the README.md).

The other benefit of the configuration model is that allows inheritable configuration. Configuration can be specified at the top-level defaults, at the package level, and at the interface level, which parameters being inherited at each level. This is a powerful way to differentiate mock generation based on individual needs.

and

Its configuration model is entirely CLI parameter based. There are no config files, no inheritable config, no use of Go templating.

I think this critic is debatable as well. As long as there is no need for just an other config file, that pollutes my repository, since everything that is needed to generate the mocks fits into the go:generate line is a good thing in my opinion. It gets even worse in my opinion, if the config files are spread through out the repository and are then combined in some sort of Configuration inheritance, since this can hurt maintainability. In regards to inheritance in config files, it might be worth to have a look at cue and the reasoning behind, why cue does not have any sort of inheritance (source, e.g. core developer Marcel van Lohuizen in "Override-style inheritance is the biggest source of complexity in configuration." in https://www.coss.community/cossc/ocs-2020-breakout-marcel-van-lohuizen-google-17i0).

style

In regards to the possible values for the configuration attribute style, I wonder if it does make sense to have the "product" names there or if we should try to find terms, that describe best the two different styles of mocks.

Generator

I wonder, if the generator could be made "generic" in the sense that it just uses Go templates again to generate the final result. Similar to how it is done in https://github.com/hexdigest/gowrap. Basically mockery would just collect the necessary information (state), that is needed to generate the mocks and pass this to the Generator, which then basically loads a Go template where the final result is generated based on the state that is passed.

I hope, this thoughts are helpful for you.

from mockery.

I am not yet familiar with the ins and outs of mockery, so I am not yet able to comment on all the aspects of the proposal.

I myself am not super familiar with moq so it's great to have you in this discussion :D

Maybe the most "challenging" thing for most users that work with moq generated mocks are the proper handling of multiple calls to the same mock in a single test case. For this, the approach with queues served us well (see matryer/moq#187 (comment), unfortunately, this tip did not yet make it into the README.md).

I was a bit confused as to why this would be a "challenge," but what you suggested (either an external counter or a queue of return values) is what I thought would be done. In fact, the reason why I like that method more is precisely because it's ugly/manual. I've found it to generally be (like 80% of the time) bad practice, so I feel the mock framework should discourage it by default due to the increased coupling it creates. The main criticisms that have been raised is that mockery encourages this sort of coupling due to how easy it is to say .EXPECT().Foo(1).Return(1).Once().

I think this critic is debatable as well. As long as there is no need for just an other config file, that pollutes my repository, since everything that is needed to generate the mocks fits into the go:generate line is a good thing in my opinion.

I agree, on the surface this is a matter of taste. I prefer centralized config files, some people prefer go:generate. In this case, our hand is forced because go:generate was in fact the sole reason for poor performance. So in mockery, we'll never go back to recommending go:generate. It's a trade off that I feel is worth it for the 5x increase in performance I've measured.

It gets even worse in my opinion, if the config files are spread through out the repository and are then combined in some sort of Configuration inheritance, since this can hurt maintainability.

This had been suggested, but I rejected the idea on the grounds that it didn't seem like a highly requested feature and there are ways around the lack of inheritable config files. So as it stands, the only inheritance is your typical 3 sources of environment, CLI, and config files (and of course the mappings within the config file itself).

In regards to the possible values for the configuration attribute style, I wonder if it does make sense to have the "product" names there or if we should try to find terms, that describe best the two different styles of mocks.

You are probably right. Maybe: expectation and function-attribute? Open to other ideas.

I wonder, if the generator could be made "generic" in the sense that it just uses Go templates again to generate the final result. Similar to how it is done in https://github.com/hexdigest/gowrap.

That's a great idea. We could probably structure a new kind of generator that does just that. Unfortunately it would be very hard to port over the current Generator that creates expectation mocks because it has a lot of in-memory Sprintf-s that construct various parts of the mock. I've been pushing aggressively to move over to a singular template string but that work isn't completed yet. Regardless, we should 100% design it in this way. The other really cool thing about this idea is that we could allow users to define their own templates to create their own style of mocks. At that point, mockery becomes this sort of meta-mocking thing and opens up the door for lots of interesting paths.

from mockery.