Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

PROPOSAL: Integration with vektra/mockery #208

Open
LandonTClipp opened this issue Sep 21, 2023 · 10 comments
Open

PROPOSAL: Integration with vektra/mockery #208

LandonTClipp opened this issue Sep 21, 2023 · 10 comments

Comments

@LandonTClipp
Copy link

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
Copy link
Owner

matryer commented Sep 22, 2023

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

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

@breml
Copy link
Contributor

breml commented Sep 22, 2023

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
Copy link
Author

@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
Copy link
Contributor

breml commented Sep 22, 2023

@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
Copy link
Author

LandonTClipp commented Sep 22, 2023

@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
Copy link
Collaborator

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
Copy link
Author

LandonTClipp commented Sep 24, 2023

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
Copy link
Author

LandonTClipp commented Sep 24, 2023

Design proposal: vektra/mockery#715

@breml
Copy link
Contributor

breml commented Sep 25, 2023

@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
Copy link
Author

@matryer @breml @sudo-suhas

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants