go-sqlmock VS mockery

There is a good lib for db tests https://github.com/DATA-DOG/go-sqlmock

Continuous Integration - Testify, sqlmock, Mockery, Github Actions

For testing DB queries I use https://github.com/DATA-DOG/go-sqlmock for unit tests. I then have a separate integration test suite that runs against all our services using Docker.

However your point is valid. Check matryer/is for unit test writing. DATA-DOG/go-sqlmock to test database interactions.

We have different ways to write our tests depending on what datastore we are using, for example if we are testing database calls that happen to be using database/sql then importing a package like github.com/DATA-DOG/go-sqlmock could work.

Another common method is to mock SQL services in the test. At present, the more popular solution is to use go-sqlmock.

I've been using https://github.com/DATA-DOG/go-sqlmock. It's pretty well documented, should be enough to get going.

I've never bothered with any ORM, but for mocking the underlying sql.DB I've been using https://github.com/DATA-DOG/go-sqlmock which is very simple and straightforward to use.

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.