matryer
matryer mocks are derived from the project at https://github.com/matryer/moq. These mocks create a struct that has a function field for each method, which you can declare in your test code.
Description¶
// Code generated by mockery; DO NOT EDIT.
// github.com/vektra/mockery
package test
import (
"sync"
)
// Ensure, that MoqRequester does implement Requester.
// If this is not the case, regenerate this file with moq.
var _ Requester = &MoqRequester{}
// MoqRequester is a mock implementation of Requester.
//
// func TestSomethingThatUsesRequester(t *testing.T) {
//
// // make and configure a mocked Requester
// mockedRequester := &MoqRequester{
// GetFunc: func(path string) (string, error) {
// panic("mock out the Get method")
// },
// }
//
// // use mockedRequester in code that requires Requester
// // and then make assertions.
//
// }
type MoqRequester struct {
// GetFunc mocks the Get method.
GetFunc func(path string) (string, error)
// calls tracks calls to the methods.
calls struct {
// Get holds details about calls to the Get method.
Get []struct {
// Path is the path argument value.
Path string
}
}
lockGet sync.RWMutex
}
// Get calls GetFunc.
func (mock *MoqRequester) Get(path string) (string, error) {
// ...
}
// GetCalls gets all the calls that were made to Get.
// Check the length with:
//
// len(mockedRequester.GetCalls())
func (mock *MoqRequester) GetCalls() []struct {
Path string
} {
// ...
}
matryer-style mocks are far simpler, and probably more intuitive, than testify-style mocks. All that's needed is to define the function that will be run when the mock's method is called.
template-data¶
moq accepts the following template-data: keys:
| key | type | description |
|---|---|---|
add-import |
list |
Add imports used by struct-preamble. Each entry requires name (the exact Go import name) and pkgPath (the import path). |
boilerplate-file |
string |
Specify a path to a file that contains comments you want displayed at the top of all generated mock files. This is commonly used to display license headers at the top of your source code. |
mock-build-tags |
string |
Set the build tags of the generated mocks. Read more about the format. |
skip-ensure |
bool |
Suppress mock implementation check, avoid import cycle if mocks generated outside of the tested package. |
stub-impl |
bool |
Return zero values when no mock implementation is provided, do not panic. |
struct-preamble |
string |
Insert Go code at the start of the mock struct, before its generated fields. This can embed types or add fields. |
with-resets |
bool |
Generates methods that allow resetting calls made to the mocks. |
Embedding types¶
Some interfaces require embedding a type from their package to implement an unexported method. For example, gRPC server interfaces require an embedded Unimplemented<ServiceName>Server. Configure each mock's struct-preamble and any imports it needs:
template: matryer
packages:
example.com/project/gen:
config:
dir: ./mocks
pkgname: mocks
interfaces:
GreeterServer:
config:
template-data:
struct-preamble: gen.UnimplementedGreeterServer
add-import:
- name: gen
pkgPath: example.com/project/gen
The preamble is literal Go code, not a Go template. A YAML block scalar (|) can contain multiple embedded types or fields. For a generic mock, use its generated type parameter names in the preamble, for example gen.UnimplementedStore[T]. When generating in the source package, use the unqualified type name and omit its add-import entry.
name is the exact qualifier used in the preamble; it may differ from the imported package's declared name. It must be a Go identifier; blank (_) and dot (.) imports are not supported. Imports from all mocks in the same generated file are combined, and repeated entries with the same path and name are deduplicated. If the name conflicts with another import or a known package declaration when generating in place, generation fails. A package already imported by a method signature must use its existing qualifier. These checks avoid silently renaming an import while leaving the literal preamble unchanged.
Mockery does not type-check the preamble. Compile and test the generated code to verify that the embedded types exist and that the mock implements the interface. These options are specific to the matryer template.
Schema¶
{
"$schema": "http://json-schema.org/draft-07/schema#",
"title": "vektra/mockery matryer mock",
"type": "object",
"additionalProperties": false,
"properties": {
"add-import": {
"type": "array",
"items": {
"type": "object",
"additionalProperties": false,
"properties": {
"name": {
"type": "string",
"minLength": 1
},
"pkgPath": {
"type": "string",
"minLength": 1
}
},
"required": ["name", "pkgPath"]
}
},
"boilerplate-file": {
"type": "string"
},
"mock-build-tags": {
"type": "string"
},
"skip-ensure": {
"type": "boolean"
},
"stub-impl": {
"type": "boolean"
},
"struct-preamble": {
"type": "string"
},
"with-resets": {
"type": "boolean"
}
},
"required": []
}