Background

Sometimes I want to use mock with other format to follow existing code base.

What

• add templates package

How to use customize template

1. add a new file under templates package like default.go
2. build
3. run mokku with specifing template name in command line argument like ./mokku -t mytemplate

Given:

type O11y interface {
	Wrap(ctx context.Context, err error, args ...interface{}) *bugsnag.Error
}

Got:

type O11yMock struct {
	WrapFunc     func(ctx context.Context, err error, args ...interface{}) bugsnag.Error
}

func (m *O11yMock) Wrap(ctx context.Context, err error, args ...interface{}) bugsnag.Error {
	if m.WrapFunc == nil {
		panic("unexpected call to Wrap")
	}
	return m.WrapFunc(ctx, err, args...)
}

the * in *bugsnag.Error is missing.

WHAT

Currently, template is fixed and built in the mokku binary. However, people want to follow their rule of project, policy, preferable, and so on. This suggestion is to support loading the template from the given environment variable.

I supposed to use with .envrc etc.

This Add method has trailing comma in parameters part.

type Calculator interface {
	Add(a int,
		b int,
	) int
}

It causes error like this.

10:30: expected statement, found ')' (and 1 more errors)
Usage:
1. Copy the interface you want to mock
2. Run 'mokku'
3. Paste the mocked implementation that has been written to your clipboard

Document the key binding to put in your .vimrc that is required to put the mock representation of the interface under the cursor in the default register by hitting (for example) <leader>m.

Allow for trailing commas in interface method signatures.

Until this change, this will fail as it adds an excessive ) character, which cannot be processed.

Closes #25.

Checklist

• [x] I have done a self-review of the PR.

Setting up the repository

This document serves as both a list of all the rules and steps to set up a very good open source Go project, and also the issue contents of the GitHub issue generated by github.com/kinbiko/go-template's astroturf.sh script that automates a bunch of these very steps.

CI

• [x] Builds against one of the 2 latest Go versions
• [x] Has golangci-lint v1.45.2 passing
• [x] Runs tests with the race detector
• [x] Runs integration tests, if applicable
• [x] Reports coverage to coveralls
• [x] Code scanning with CodeQL

Community Standards

• [x] Description w/ tags
• [x] README
• [x] Code of conduct
• [x] Contributing guideline
• [x] License
• [x] Issue template(s)
• [x] Pull request template
• [x] CODEOWNERS

GitHub settings

• [x] Wiki pages disabled
• [x] Sponsorship enabled
• [x] Projects disabled (my OSS work is managed in a central project board)
• [x] GitHub archive program enabled
• [x] Discussions disabled
• [x] Merge commits disabled
• [x] Squash merging enabled
• [x] Rebase merging disabled
• [x] Suggest updating branches enabled
• [x] Auto-merge disabled
• [x] Auto-delete head branches enabled
• [x] Limit "approve" or "request changes" to users with explicit permissions
• [x] Default branch is main, with the following branch protection rules enabled (everything else disabled):
  • [x] Require PRs before merging (no approvals required, don't dismiss PR approvals on new commits, don't require codeowner review)
  • [x] Linear history enabled (assumption: only enabling squash merges globally means linear history in default branch)
• [x] Allow kinbiko and select non-kinbiko actions only:
  • [x] Allow actions created by GitHub enabled
  • [x] Allow actions by Marketplace verified creators enabled
  • [x] shogo82148/[email protected] added as allowed action
• [x] Require approval before running actions for first-time contributors
• [x] GitHub actions approving PRs disabled
• [x] Dependabot alerts enabled for security vulns
• [x] Dependabot updates enabled for security vulns
• [x] Code scanning (CodeQL) enabled
• [x] Consistent labels:
  • bug
  • dependencies
  • documentation
  • enhancement
  • good first issue
  • help wanted
  • question

README

• [x] Has tags:
  • [x] Build status
  • [x] Coverage percentage
  • [x] Go report link
  • [x] Latest version
  • [x] Godoc with link to pkg.go.dev
  • [x] License tag
• [x] Explains the why and then the what.
• [x] Usage information incl any installation guidelines
• [x] Link to docs

ISSUE_TEMPLATE.md

Should provide a template for how bug reports should be structured. Should be as small as possible but include the following:

• Indication that the template is for bug reports only, and can be ignored for other types of issues (e.g. ideas, missing docs etc.).
• H2 headers for 'What I did', 'What I expected', 'What happened', 'Suggestions'. Suggestions are optional.
• Whether or not you're interested in addressing the bug yourself.
• HTML comments containing instructions for adding labels.

PULL_REQUEST_TEMPLATE.md

Should include a reminder to create/show interest in an issue before raising a pull request, and add a link to the issue within the pull request description.

Code changes

Once the issue template has been set up then we should include a link to create a new issue in the error messages in the case of a failed mock generation.

In the future mokku is likely to support different options (e.g. whether or not to include godocs on the generated type, make mocks safe for concurrent access, whether or not to store the arguments per call to a mocked method, etc.). In order to not having to break backwards compatibility (even before v1.x.x) this commit identifies the desired signature upfront.

Document (in the README) how to integrate mokku with goland. If there's an even more convenient method of shelling out and copying, e.g. binding shelling out to run 'mokku' to a key binding, then that's preferable.

Right now the error messages are directed to the developer and not the end user. The error messages should be re-written to be actionable by the user.

Did

Copied the following struct:

type foobar interface {
    baz(context.Context, int)
}

and ran mokku, and pasted the result.

Expected

A mock struct that compiles.

Got

A compile error, because the resulting mocked method attempts to pass context as a parameter to the underlying Func.

Suggestion

In the case that parameters are not named, we should create a dummy variable name. a,b, etc is probably fine for unnamed parameters. If users have more than 26 variable names then, well... there are bigger design issues at hand.