Hm, at least the handling of interface definitions seems very unidiomatic to me, specifically implementation packages also containing the interface definitions. At least those interfaces are not returned, but structs instead.
Usage of the internal/ package would make sense too. All in all this seems as it would benefit from some go specific patterns.
Options would be nice and i still do not understand the benefit of build tag based config compared to env or flag based approaches.
The article is not very good, as some of the points made are just wrong ( the whole part about VMs for example). It seems that this is just the result of a short internet search without much in the way of understanding.
Why not define the interfaces where they are used?
Hm, at least the handling of interface definitions seems very unidiomatic to me, specifically implementation packages also containing the interface definitions. At least those interfaces are not returned, but structs instead.
Usage of the internal/ package would make sense too. All in all this seems as it would benefit from some go specific patterns.
Options would be nice and i still do not understand the benefit of build tag based config compared to env or flag based approaches.
Anyone have any experience with this & do you think it is usable in proiduction? Seems like a nice way to make FS heavy code more testable.
The article is not very good, as some of the points made are just wrong ( the whole part about VMs for example). It seems that this is just the result of a short internet search without much in the way of understanding.
Seems like a bot test