PROPOSAL: Integration with vektra/mockery

[LandonTClipp]

Hi @matryer, I don't have twitter so I don't know a better way to contact you.

I'm the maintainer of https://github.com/vektra/mockery. I have been a big fan of moq for some time now, and I believe this style of mocking has a lot of benefits over what I consider to be the "heavyweight" approach of testify argument-matching. I have been working on a number of pretty serious performance improvements to mockery that currently makes it orders of magnitude faster than any other mocking solution out there, including dare I say, moq itself.

I thought it would be very useful to the Go community more broadly if we integrated moq-style mocks into mockery, which could be done fairly easily as an additional configurable parameter. I know you're a very busy individual over at Grafana so I won't take too much of your time, but let me know what you think of this and if you'd have any reservations/objections.

[matryer]

Hey Landon, thanks for reaching out. By all means go for it.

And also, shall we do a Go Time episode on Mocking?

[breml]

Hi @LandonTClipp
I hope you don't mind me asking back on your proposal just to get the correct understanding.
With your proposal implemented in mockery, the goal would be, that mockery can be used as "drop-in" replacement for moq, such that it generates the same mocks for a given interface?

[LandonTClipp]

@matryer Great! Okay, I'll put it on the roadmap :) I would love to do an episode, I'm fairly busy the next couple of weeks but let's get in touch and schedule something.

@breml That is the idea. It wouldn't be a drop-in replacement in the sense that CLI options would be the same, but if you configured it the "mockery" way then the end result would be practically identical to moq.

[breml]

@LandonTClipp Thanks for the explanation. I mainly care about the generated code, such that a switch from moq to mockery would not cause a lot of code changes. In my case, changing some go:generate lines and maybe add a config file is acceptable, especially if this leads to faster generation time for the mocks.
In the best case, I would prefer, if the generated mocks would be identical to the ones that are generated by moq.

Is your request kind of a request to join forces (e.g. for maintenance) or is it more of a "polite takover"?

One last thing, as soon as you have an issue or a PR, can you mention it here? Thanks.

[LandonTClipp]

@breml I understand the importance of keeping the generated mocks strictly equivalent, it would be a ginormous pain if you had to modify your tests for any breaking changes. I don't think there would be anything that would warrant breaking changes, but regardless I'll be sure to weigh your request heavily.

If Mat would like to join forces, I'm all for adding him as a maintainer. My main motivation here is to combine the benefits of moq with the large configuration and performance gains I've implemented in mockery. I don't know who else has write power here, @sudo-suhas ? I would like to hear other contributor's opinions as well.

The only thing I'll enforce is that I have ultimate authority on project direction, so any large feature additions would have to get my (or Mat's, theoretically) approval. We could also federalize into CODEOWNER-ship, but let me not get ahead of myself.

[sudo-suhas]

There are some existing issue reports regarding performance so I was thinking of referencing the changes in mockery to see if any of those improvements could be carried over. But what you are suggesting would be better so I too an in favor of it. However, if it is possible, could you share a design document on what would be the proposed user interface and the high level changes that you are thinking of making in either mockery or moq?

[LandonTClipp]

However, if it is possible, could you share a design document on what would be the proposed user interface and the high level changes that you are thinking of making in either mockery or moq?

Absolutely, I'll start an issue over at mockery with the design proposal.

[LandonTClipp]

Design proposal: vektra/mockery#715

[breml]

@LandonTClipp Thanks for the link to the design proposal, I will have a look.
In regards to my relation to moq: I am a long time user of moq (since 2017, if I remember correctly) in a multitude of projects in professional and personal context and therefore the future of moq is of relevance for me. I have been a contributor in the past and I follow issues and PR closely and tried to contribute with comments and reviews. I do not have write permissions to the repository.

[LandonTClipp]

@matryer @breml @sudo-suhas

Here is a working implementation of moq-in-mockery. Let me know your thoughts: vektra/mockery#725