Support for mocking core types

[gr8routdoors]

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.

[matryer]

@gr8routdoors what use cases do you have for this? Would it be mocking interfaces only?

[tanoinc]

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!

[matryer]

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.

[matryer]

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.

[tanoinc]

True, for this simple specific case, I ended up creating a mock manually. But I could imagine other scenarios.

Thanks Mat!

[msbit]

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

[msbit]

Or:

moq $(go env GOROOT)/src/net/http RoundTripper

[breml]

You might also consider using a type alias or simply copying the interface to your code, as discussed in #172 (comment)