Thanks for the direct link, medium wanted me to sign in.
Looking over the example code, my gut reaction is "don't do this, this is an anti pattern and bad."
They replaced a simple, linear, hand written, and easily understandable few lines of code with code generation and indirection.
The idiomatic way to solve this problem is to have struct properties and/or a constructor that takes interfaces. In the concrete implementation, you pass the real dependencies. In the tests, you pass fakes (test doubles that match the interface). It requires no code gen.
My team is spinning up a new http service. It took me less than a morning to refactor the app from gross globals to creating server instances that can be unit tested in parallel. There are three core dependencies and the unit testing is super easy. On any dependency, set its fake to have an error. Validate the error is handled the way you want. Done.
Dependency injection is solved for Go with interfaces. Also note the Go Proverb and keep interfaces small.
Looking over the example code, my gut reaction is "don't do this, this is an anti pattern and bad."
They replaced a simple, linear, hand written, and easily understandable few lines of code with code generation and indirection.
The idiomatic way to solve this problem is to have struct properties and/or a constructor that takes interfaces. In the concrete implementation, you pass the real dependencies. In the tests, you pass fakes (test doubles that match the interface). It requires no code gen.
My team is spinning up a new http service. It took me less than a morning to refactor the app from gross globals to creating server instances that can be unit tested in parallel. There are three core dependencies and the unit testing is super easy. On any dependency, set its fake to have an error. Validate the error is handled the way you want. Done.
Dependency injection is solved for Go with interfaces. Also note the Go Proverb and keep interfaces small.