Open gr8routdoors opened 1 year ago
@gr8routdoors what use cases do you have for this? Would it be mocking interfaces only?
Hey, thanks for all the work you're doing, this project is great!
Regarding this issue, I have a similar use case, for example I'm using a RoundTripper
implementation as a dependency, for a Http client which can hold some middlewares. For the unit tests, I need to mock an interface from standard lib (net/http
holds the RoundTripper
interface).
If there's a way to do it (that I don't know), please excuse me 😅
Thanks again!
Honestly, it might be easier to write a quick RoundTripper
function in your test code, and use that - it can sometimes be simpler.
This doesn't negate the discussion around this feature though. Just trying to understand it a bit more.
I can see the argument to have them look/feel the same as the other mocks though. So yeah, this feels more and more like something we should support.
True, for this simple specific case, I ended up creating a mock manually. But I could imagine other scenarios.
Thanks Mat!
Without any real testing, it looks like this works:
moq /opt/local/lib/go/src/net/http RoundTripper
but it would be nice to have an install agnostic way to spell /opt/local/lib/go/src
Or:
moq $(go env GOROOT)/src/net/http RoundTripper
You might also consider using a type alias or simply copying the interface to your code, as discussed in https://github.com/matryer/moq/issues/172#issuecomment-1084369939
Have you considered adding the ability to mock built-in golang types? It seems like a mixed bag out there of libraries and people hand rolling various core type mocks. Seems like this might be useful and potentially doable through additions to the registry loading logic.