[WiP] Add `interceptor` template

[itroot]

This PR adds an ability to generate a "mock" wrapper (that one that actually does not wrap the interface, but mocks it's methods). This is quite a handy technique of making mocks. Compared to usual way it gives compile-time verification of a correct code and ease of refactoring. Couple of things to figure out:

• [x] it is possible to proxy a call to a implementation (too keep gowrap philosophy of wrapping). Should we do that?
• [ ] naming of the vars + ~adding something like CheckExpectations to the template.~

Feedback is welcomed! :pray:

[hexdigest]

Hey @itroot,

Have you tried minimock ?

It's working on top of GoWrap generator package and does way more than this template.

[itroot]

@hexdigest thanks for looking into this PR! :pray:

Have you tried minimock ? It's working on top of GoWrap generator package and does way more than this template.

:heavy_check_mark: Yes, I did. Minimock, as a lot of other mocks libs are a bit heavy and complicated. Often there is no need for all of those expect stuff, and it would be nice just to be able to redefine a method behaviour by setting a function handler like this: https://github.com/hexdigest/gowrap/blob/2bc2fd897245a64302a0c767c337c8897707307a/templates_tests/interface_with_mock_test.go#L19-L22 This technique is much more flexible (pure IMO) and works well because of autocomplete that every modern editor/IDE supports. I often found myself writing mocks of this kind manually very frequently, and then I tried couple of generators and gowrap was the best fit :+1: . So I made a template akin the one I put into this PR and still using it for this purpose. Now I decided to share it in the PR.

However I do acknowledge that this mock use-case could be not natural for gowrap. Do you think it is ok?

• if it's OK, I can improve this PR if you have any suggestions
• if you think it's not a good fit, I tempted to suggest to refactor it into a very similar wrapper that proxies all calls to the original interface by default, but falls back to "mock handler" (or whatever name we can choose, it could be interceptor or something) if this mock handler is set. (Counters logic could be dropped.). That would allow easily wrap any method of an interface, could be useful not only for mocks.
• if you still think it's no way this gonna make it in the repo, I will go away and will happily use my template as a standalone one :slightly_smiling_face: . Still any feedback is highly appreciated!

[hexdigest]

https://github.com/hexdigest/gowrap/blob/2bc2fd897245a64302a0c767c337c8897707307a/templates_tests/interface_with_mock_test.go#L19-L22

This technique is much more flexible (pure IMO) and works well because of autocomplete that every modern editor/IDE supports.

There's exactly same functionality in minimock the only difference is that you're have to call

m.MyFuncMock.Set(func(ctx context.Context, a1 string, a2 ...string) (result1 string, result2 string, err error) { 
    called = true 
    return "", "", nil 
 })

rather than direct assignment to a functional field and there's nothing complicated in it.

In general we have a collection of decorators here and I'd prefer it to be so. Even though I understand that many other things can be generated out of interfaces' declarations. If we deploy this template here it inevitably will be extended with other features and at the end of the day it will become a minimock which is already exists and covers all potential use-cases for mocks.

[itroot]

Thanks for the hint on how to use minimock.

If mock template doesn't fit gowrap that is fine. I have a last resort in the commit 575f661 with an "interceptor". Will that have a chance to be merged (if not, I will close the PR)? Thanks!

Basically what it does is: https://github.com/hexdigest/gowrap/blob/575f66140dd53e5022b2d9203d26378179355522/templates_tests/interface_with_interceptor.go#L38-L46

[itroot]

@hexdigest does interceptor template approach have a chance to land into the repo? Thanks.

[itroot]

:pensive: