gotests VS gomock

I use https://github.com/cweill/gotests to generate the test scaffolding.

You can save yourself a minute and generate the test case boilerplate for your with https://github.com/cweill/gotests :)

If you want to write tests, DI also can help you! Sometimes you need mocks for tests (to be independent of some modules like logger in tests), you have to generate it! There is an amazing tool for this task in go - GoMock. When you describe only needed methods in DI interface, the GoMock generate mocks just for those methods - it is faster and more readable in practice, than hundreds methods in mocks.

I really disagree with this statement. In fact, there is a Google-developed mocking tool in the official Go organization - https://github.com/golang/mock. I am not a huge fan of mocking and I avoid it when I can, but there is nothing that indicates you must be writing Java code in Go if you're using mocks. You'll even find the use of mocks in the Go standard library test code.

Gomock or mockery?

I used to use Mockery, but it was unmaintained for a long time, and not that great, so these days it's Mock, which is nicer in several ways.

Honestly curious - why wouldn't you use something like https://github.com/golang/mock to generate your mocks from an interface. Way more productive, consistent and cleaner. Spend more time and focus on your business logic rather than something that's already been solved.

Sorry for badly explaining. Issue explaining it better than me: https://github.com/golang/mock/issues/324

https://github.com/golang/mock - Auto generate mocks from interfaces for unit testing

BTW https://github.com/golang/mock is way more propular and does similar things.

The first day, I wrote my tests for some GET routes. We use something called go-mock in our unit tests, which allows you to only focus on testing the function you're writing. Because of this, I found that you still needed to have a good idea of the code you want to write while writing out the tests. In our case, we needed to mock out our calls to an external API. If you asked for my opinion after the first day, I would've told you that I could envision the benefits of TDD for something like end to end testing, where it's a black box and you're only verifying that the output is what's expected from a given input. But for unit testing, it wasn't any different than just writing the code first.