Allow specifying interfaces to be mocked via mocktail argument (vs mock_test.go)

[tigerinus]

In our project, we use a codegen https://github.com/deepmap/oapi-codegen to generate client under a path ./codegen and this path is ignored in .gitignore (for obvious reason - the code is generated on the fly per build)

The codegen automatiically creates a ClientInterface interface, e.g.

// The interface specification for the client above.
type ClientInterface interface {
	// SubscribeActionWS request
	SubscribeActionWS(ctx context.Context, sourceId SourceID, params *SubscribeActionWSParams, reqEditors ...RequestEditorFn) (*http.Response, error)

	// TriggerAction request with any body
	TriggerActionWithBody(ctx context.Context, sourceId SourceID, name ActionName, contentType string, body io.Reader, reqEditors ...RequestEditorFn) (*http.Response, error)

	TriggerAction(ctx context.Context, sourceId SourceID, name ActionName, body TriggerActionJSONRequestBody, reqEditors ...RequestEditorFn) (*http.Response, error)

	// GetActionTypes request
	GetActionTypes(ctx context.Context, reqEditors ...RequestEditorFn) (*http.Response, error)

	// RegisterActionTypes request with any body
	RegisterActionTypesWithBody(ctx context.Context, contentType string, body io.Reader, reqEditors ...RequestEditorFn) (*http.Response, error)

	RegisterActionTypes(ctx context.Context, body RegisterActionTypesJSONRequestBody, reqEditors ...RequestEditorFn) (*http.Response, error)

Because ./codegen is ignored, to use mocktail we will have to inconveniently create a mock_test.go as part of the build process before calling mocktail.

It'd be nice to allow passing ClientInterface (together with package name/path) via mocktail arguments. E.g.

mocktail --interface ./codegen#ClientInterface

[emilevauge]

Thank you for the suggestion, we have set the status to enhancement. However, this would not make it to our roadmap as we are focused elsewhere. If a community member would like to build it, let us know, and we will work with you to ensure you have all the information needed to merge it.

We prefer to work with our community members at the beginning of the design process to ensure that we are aligned and can move quickly with the review and merge process. Let us know here or create a PR before you start, and we will work with you there.