counterfeiter VS gomock

then just replace whole function, don't generate manually the mock '__') or it would get out of hand fast, you can just use codegen that static typed like https://github.com/maxbrunsfeld/counterfeiter

Yes, that's a good way to do that; there are a lot of packages that allow you to mock and spy the calls if you're looking for one that generates the code for you I can recommend counterfeiter, I also have a short blog that covers it.

I prefer https://github.com/maxbrunsfeld/counterfeiter

counterfeiter is another tool, it creates mocks, stubs and spies; here is a short blog I wrote covering it.

for dependency injection I suggest you use https://github.com/maxbrunsfeld/counterfeiter, but if you using really fast database (that can spawn fast using docker and has fast trx/sec) you can use it directly without dependency injection with https://github.com/ory/dockertest

Agree with u/mmknightx there is a tool that assist in creating fake or mock classes for your interfaces https://github.com/maxbrunsfeld/counterfeiter

Another alternative to use would be counterfeiter, it generates a type from your interface that could be used as a mock, stub or spy. I wrote a short post covering that tool if you're interested.

The commit mentions this rather sad thread: https://github.com/golang/mock/pull/627#issuecomment-1605169...

IDE: use whatever make you productive. I personally use vscode. VCS: git, as golang communities use github heavily as base for many libraries. AFAIK Linter: use staticcheck for linting as it looks like mostly used linting tool in go, supported by many also. In Vscode it will be recommended once you install go plugin. Libraries/Framework: actually the standard libraries already included many things you need, decent enough for your day-to-day development cycles(e.g. `net/http`). But here are things for extra: - Struct fields validator: validator - Http server lib: chi router , httprouter , fasthttp (for non standard http implementations, but fast) - Web Framework: echo , gin , fiber , beego , etc - Http client lib: most already covered by stdlib(net/http), so you rarely need extra lib for this, but if you really need some are: resty - CLI: cobra - Config: godotenv , viper - DB Drivers: sqlx , postgre , sqlite , mysql - nosql: redis , mongodb , elasticsearch - ORM: gorm , entgo , sqlc(codegen) - JS Transpiler: gopherjs - GUI: fyne - grpc: grpc - logging: zerolog - test: testify , gomock , dockertest - and many others you can find here

Normally I like to generate everything with Mockgen and test it using table driven test.

Looking at gomock's commit history, it seems like there hasn't been much activity on the project in a couple of years. I'm wondering if this is the case of software being mostly done and just in maintenance mode, or if gomock is falling behind. The reason I fear for the latter is there are still issues being opened up that don't seem to be engaged very much.

Yeah, that would work just fine. Nevertheless, as your business logic gets more complicated, you will want to test more scenarios and mocks will get complicated fast. In these cases tools like gomock really shine and make your life easier. I understand that this is a just-for-fun project, but it's never too early to experiment with a popular solution, especially if you plan on using Go professionally in the future.

Unit tests are leveraged to test individual units of code. As such it is not recommended for a developer to scaffold entire dependencies for the sake of testing a single object. Due to the way Go's specific implementations work, I've learned over time to declare interfaces for a lot of the structs that I use in Go. Interfaces not only define a contract for which struct-based implementations should adhere, but they also provide a mechanism for which struct methods can be mocked. While I've experimented with the mock package in testify, I've come to prefer the mock functionality which is provided by mockgen.

gomock can also be great for testing when used sparingly. Mocking out one or two calls is great, anymore than that and it becomes exponentially harder to reason about

Where we do use mocks, we primarily use GoMock.