mockery VS moq

Mockery is a great tool to generate mocks based on interfaces, that way our unit tests can look like this (pseudocode):

Since mockery uses a lot of interface{} magic, adding arguments or return values to interfaces and regenerating the mocks does not get the compiler to complain about existing, now invalid, usages of the mocks. This means that I have to track them down manually. Or, if I'm brave enough, try my hand at a few crazy regexes that never get the job 100% done.

go-mocky does not use interface{}s, and thus can't hide changes to function signatures from the compiler; whenever a mock has been updated and the function signature has changed, the compiler will complain for all existing tests. This means that I can now catch errors at compile/lint time instead of runtime.

Another added benefit is that the go-mocky mocks are dead simple and very easy to write and maintain by hand, should the need ever arise.

[1]: https://github.com/vektra/mockery

+1 on testify. Started out with that, and it, together with its mocks and the framework mockery are a brilliant combination, assuming you are into testing with mocks to some extent

I use mockery to generate mocks based on my interfaces: https://github.com/vektra/mockery

There are some packages in my project that are not used in the source code, but they're used as commands (i.e. https://github.com/vektra/mockery https://github.com/rubenv/sql-migrate).

Gomock or mockery?

As a Go newbie, the on-boarding process to Golang went relatively smoothly except a small glitch when it came to search for a mocking framework to test out a Go class implementation. I was a bit surprised to realize that I was not able to find a on-shelf tool to help me mock a class method. It might be an edge case scenario that I wanted to mock a class method, but I do believe that this is a valid use case, so I went ahead to spend a weekend building such a tool: mockcompose. It was originally aimed to just solve this one particular use case, therefore, it had to be used together with mockery (one of the great tools I found during my search in the period). I later refined the tool to cover mocking code generation for Go interfaces and functions, mockcompose can now be used in most of Go unit test scenarios. Please check it out and give it a try, I hope the tool is useful, feel free to drop your feedback and share with your opinion there.

Just replaced mockery generated mocks with https://github.com/matryer/moq Alot cleaner imo at least for me

btw, you can avoid making such mocks manually by using https://github.com/matryer/moq, which will generate such mocking code for you

I like the way of matryer/moq a lot. Basically, it generates a func for each of the methods of an interface, therefore the behaviour is clear to everyone without too much abstraction.

https://github.com/matryer/moq Because it is simple and doesn’t look like magic. Fits go.

This one is easy to use, simple, powerful and idiomatic https://github.com/matryer/moq

I happen to use this https://github.com/matryer/moq because it more or less makes the mock I would handwrite

I use github.com/matryer/moq which is so simple to use and covers most cases and doesn't introduce dark magic to the code 😆

https://github.com/matryer/moq is a good package btw - point it at your HTTPClientI interface and it'll autogenerate pretty close to a drop in replacement for your mockHTTPClient code. It's not worth the dependency if this is your only mock and the interface only has one method on it, but if the interfaces you want to mock get bigger then it's very useful.