gomock VS monkey

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.

Where we do use mocks, we primarily use GoMock.

Currently migrating from moq to https://github.com/golang/mock

I use gomock or mockery for mocking the interfaces and testify for evaluating tests

As every software, the operator needs to be tested. In our case, we use two types of tests: Unit and E2E. For testing, usually mock code generation is used (for example, via golang/mock). We didn't like this option, so we decided to use Testify's mock module that allows to mock required function interfaces using the reflection API—the interfaces used to configure Tarantool.

In all other layers, my repositories are mocked using https://github.com/golang/mock

This person did not read the license of the original library https://github.com/bouk/monkey/blob/master/LICENSE.md

I am a new gopher. I was looking into the Monkey Patching module and it is archived now. I was wondering if there is an alternative for that.

Here is an example of this in Go - but as he says, don't actually do this. https://github.com/bouk/monkey

I discovered this lib a few days ago. https://github.com/bouk/monkey it allows you to monkey patch entire functions, replacing them by whatever you want. Perfect for mocking. It's simple to use. The program is hard patching the code using assembly to replace the function address at runtime. You should not use this lib out of your tests since it's absolutely not safe. It's only compatible with linux and windows. But it works great!

From the explaining blog post [0]

> If you’re not interested in how it works and you just want to do monkey patching, then you can find the library here.

Also

> Wrapping it up in a nice library

> I took the above code and put it in an easy to use library. It supports 32 bit, reversing patches, and patching instance methods. I wrote a couple of examples and put those in the README.

Then in the README[1]:

> Make sure you read the notes at the bottom of the README if you intend to use this library.

Either the author is confused or has decided that he doesn't want to maintain an hack. Anyway license is pretty clear.

There was an HN thread[2] when it was released.

[0] https://bou.ke/blog/monkey-patching-in-go/

[1] https://github.com/bouk/monkey

[2] https://news.ycombinator.com/item?id=9290917

"This is as unsafe as it sounds and I don't recommend anyone do it outside of a testing environment."

[1]: https://github.com/bouk/monkey#i-thought-that-monkeypatching...