You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As a follow up on #208, I've successfully integrated moq-style mocks into the mockery project, such that users may generate either mockery-style or moq-style mocks.
I've released a number of alpha builds and will begin testing throughout the coming weeks. Documentation here: https://vektra.github.io/mockery/v3/
Some things to note:
It's very very alpha, but it seems to work reliably and without much fuss.
The docs are going to be a living work of art, so expect some cobwebs and skeletons.
The real meat-and-potatoes of this can be seen in the docs here where the exact template can be selected. And, you can even provide your own template!
I drew heavy inspiration from all the contributors here, and even shamefully copy-pasted large swaths of this project because its implementation, especially in regards to source parsing, was just better in many regards. I am working on getting proper git attributions in line if anyone cares (and if not, please say because it would save me a lot of time. However, I can't claim work for myself!).
You may be asking "why fold the two projects together?" Well:
Mockery parsing is way faster for large projects. Any source code parsing project that relies on //go:generate directives is doomed to have terrible big-O speed due to the fact that they re-parse the entire source syntax tree (including all dependencies for each file) for every //go:generate instantiation. mockery v2 and v3 do not do this, which leads to orders of magnitude performance increases.
Mockery has a rich and flexible config scheme that allows controlling code generation for an entire project in an easily grok-able way.
moq-style mocks are actually just better in general due to their simplicity, so it's closer to the Go ethos. I've come to the opinion that moq mocks should be pushed more than mockery mocks.
This effort unlocks a key feature: allowing users of mockery to pass it their own templates. The open source community is vibrant and will no doubt come up with novel ideas. mockery and moq combining forces solves the interface parsing problem (which is not trivial) and allows users to focus on writing their own interface implementations.
I'm happy to add any admin or write-level contributors from moq over to mockery if they are interested. Forward any questions or discussions to the mockery repo. Thanks!
As a follow up on #208, I've successfully integrated moq-style mocks into the mockery project, such that users may generate either mockery-style or moq-style mocks.
I've released a number of alpha builds and will begin testing throughout the coming weeks. Documentation here: https://vektra.github.io/mockery/v3/
Some things to note:
The real meat-and-potatoes of this can be seen in the docs here where the exact template can be selected. And, you can even provide your own template!
I drew heavy inspiration from all the contributors here, and even shamefully copy-pasted large swaths of this project because its implementation, especially in regards to source parsing, was just better in many regards. I am working on getting proper git attributions in line if anyone cares (and if not, please say because it would save me a lot of time. However, I can't claim work for myself!).
You may be asking "why fold the two projects together?" Well:
//go:generate
directives is doomed to have terrible big-O speed due to the fact that they re-parse the entire source syntax tree (including all dependencies for each file) for every//go:generate
instantiation. mockery v2 and v3 do not do this, which leads to orders of magnitude performance increases.moq
-style mocks are actually just better in general due to their simplicity, so it's closer to the Go ethos. I've come to the opinion thatmoq
mocks should be pushed more thanmockery
mocks.mockery
to pass it their own templates. The open source community is vibrant and will no doubt come up with novel ideas.mockery
andmoq
combining forces solves the interface parsing problem (which is not trivial) and allows users to focus on writing their own interface implementations.I'm happy to add any admin or write-level contributors from
moq
over to mockery if they are interested. Forward any questions or discussions to the mockery repo. Thanks!CC: @sudo-suhas @matryer @breml
The text was updated successfully, but these errors were encountered: