template parameter.
+template parameter.An output file may contain multiple mocks, but the only rule is that all the mocks in the file must come from the same package. Because of this, mocks for different packages must go in different files.
outpkg to specify the package name of the generated mocks.
packagespackagesnullrecursiverecursivefalsetrue on a particular package, mockery will recursively search for all sub-packages and inject those packages into the config map.Additionally, this issue only happens when compiling mockery from source, such as with go install. Our docs recommend not to use go install as the success of your build depends on the compatibility of your Go version with the semantics in use. You would not encounter this issue if using one of the installation methods that install pre-built binaries, like downloading the .tar.gz binaries, or through brew install.
There might be instances where you want a mock to return different values on successive calls that provide the same arguments. For example, we might want to test this behavior:
-// Return "foo" on the first call
-getter := NewGetter()
-assert(t, "foo", getter.Get("key"))
-
-// Return "bar" on the second call
-assert(t, "bar", getter.Get("key"))
-This can be done by using the .Once() method on the mock call expectation:
mockGetter := NewMockGetter(t)
-mockGetter.EXPECT().Get(mock.anything).Return("foo").Once()
-mockGetter.EXPECT().Get(mock.anything).Return("bar").Once()
-Or you can identify an arbitrary number of times each value should be returned:
-mockGetter := NewMockGetter(t)
-mockGetter.EXPECT().Get(mock.anything).Return("foo").Times(4)
-mockGetter.EXPECT().Get(mock.anything).Return("bar").Times(2)
-Note that with proper Go support in your IDE, all the available methods are self-documented in autocompletion help contexts.
-Consider if we have a function func Bar(message ...string) error. A typical assertion might look like this:
We might also want to make an assertion that says "any number of variadic arguments":
- -However, what we've given to mockery is ambiguous because it is impossible to distinguish between these two intentions:
-This is fixed in #359 where you can provide unroll-variadic: False to get back to the old behavior. Thus, if you want to assert (1), you can then do:
If you want to assert (2), you must set unroll-variadic: True. Then this assertion's intention will be modified to mean the second case:
An upstream patch to testify is currently underway to allow passing mock.Anything directly to the variadic slice: https://github.com/stretchr/testify/pull/1348
If this is merged, it would become possible to describe the above two cases respectively:
-// case 1
-m.On("Bar", mock.Anything).Return(nil)
-// case 2
-m.On("Bar", []interface{}{mock.Anything}).Return(nil)
-References:
-The versioning in this project applies only to the behavior of the mockery binary itself. This project explicitly does not promise a stable internal API, but rather a stable executable. The versioning applies to the following:
-What the version does not track:
+The mockery project follows the standard Semantic Versioning Semantics. The versioning applies to the following areas:
go get-ing mockery with new or old versions of Go.template: "file://".Mockery is not meant to be used as an imported library. Importing mockery code in external modules is not supported.
main¶When your interfaces are in the main package, you should supply the --inpackage flag.
This will generate mocks in the same package as the target code, avoiding import issues.
Alpha Test
Mockery v3 is currently in alpha and should not be used for production.
Mockery is a project that creates mock implementations of Golang interfaces. It inspects source code and generates implementations of the interface that aid in testing.
In addition to providing a number of different styles of mocks, mockery also allows users to provide their own template files that will then be rendered using a set of template data, methods, and functions that provide comprehensive typing information about the Go interface in question.
"},{"location":"#why-mockery","title":"Why mockery?","text":"
When you have an interface like this:
db.gotype DB interface {\n Get(val string) string\n}\nand a function that takes this interface:
db_getter.gofunc getFromDB(db DB) string {\n return db.Get(\"ice cream\")\n}\nWe can use simple configuration to generate a mock implementation for the interface:
.mockery.yamlpackages:\n github.com/org/repo:\n interfaces:\n DB:\n$ mockery\n05 Mar 23 21:49 CST INF Starting mockery dry-run=false version=v3.0.0\n05 Mar 23 21:49 CST INF Using config: .mockery.yaml dry-run=false version=v3.0.0\n05 Mar 23 21:49 CST INF Generating mock dry-run=false interface=DB qualified-name=github.com/org/repo version=v3.0.0\nWe can then use the mock object in a test:
db_getter_test.goimport (\n \"testing\"\n\n \"github.com/stretchr/testify/assert\"\n)\n\nfunc Test_getFromDB(t *testing.T) {\n mockDB := NewMockDB(t)\n mockDB.EXPECT().Get(\"ice cream\").Return(\"chocolate\").Once()\n flavor := getFromDB(mockDB)\n assert.Equal(t, \"chocolate\", flavor)\n}\n//go:generate commands.Get Started
"},{"location":"configuration/","title":"Configuration","text":""},{"location":"configuration/#example","title":"Example","text":"All configuration is specified in a .mockery.yml file. An example config file may look like this:
all: False\ntemplate-data:\n boilerplate-file: ./path/to/boilerplate.txt\ntemplate: mockery\npackages:\n github.com/vektra/example:\n config:\n # Make use of the template variables to place the mock in the same\n # directory as the original interface.\n dir: \"{{.InterfaceDir}}\"\n filename: \"mocks_test.go\"\n outpkg: \"{{.PackageName}}_test\"\n mockname: \"Mock{{.InterfaceName}}\"\n interfaces:\n Foo:\n Bar:\n config:\n # Make it unexported instead\n mockname: \"mock{{.InterfaceName}}\"\n Baz:\n # Create two mock implementations of Baz with different names.\n configs:\n - filename: \"mocks_baz_one_test.go\"\n mockname: \"MockBazOne\"\n - filename: \"mocks_baz_two_test.go\"\n mockname: \"MockBazTwo\"\n io:\n config:\n dir: path/to/io/mocks\n filename: \"mocks_io.go\"\nThese are the highlights of the config scheme:
template parameter.An output file may contain multiple mocks, but the only rule is that all the mocks in the file must come from the same package. Because of this, mocks for different packages must go in different files.
"},{"location":"configuration/#parameter-descriptions","title":"Parameter Descriptions","text":"name templated default descriptionall false Generate all interfaces for the specified packages. _anchors {} Unused by mockery, but allowed in the config schema so that you may define arbitrary yaml anchors. config \"\" Set the location of the mockery config file. dir \"mocks/{{.SrcPackagePath}}\" The directory where the mock file will be outputted to. exclude-subpkg-regex [] A list of regular expressions that denote which subpackages should be excluded when recursive: true exclude-regex \"\" When set along with include-regex, then interfaces which match include-regex but also match exclude-regex will not be generated. If all is set, or if include-regex is not set, then exclude-regex has no effect. filename \"mock_{{.InterfaceName}}.go\" The name of the file the mock will reside in. force-file-write false When set to force-file-write: true, mockery will forcibly overwrite any existing files. formatter \"goimports\" The formatter to use on the rendered template. Choices are: gofmt, goimports, noop. include-regex \"\" When set, only interface names that match the expression will be generated. This setting is ignored if all: True is specified in the configuration. To further refine the interfaces generated, use exclude-regex. log-level \"info\" Set the level of the logger mockname \"Mock{{.InterfaceName}}\" The name of the generated mock. outpkg \"{{.PackageName}}\" Use outpkg to specify the package name of the generated mocks. packages null A dictionary containing configuration describing the packages and interfaces to generate mocks for. pkgname \"{{.SrcPackageName}}\" | The#!go package name` given to the generated mock files. recursive false When set to true on a particular package, mockery will recursively search for all sub-packages and inject those packages into the config map. replace-type {} Use this parameter to specify type replacements. tags \"\" A space-separated list of additional build tags to load packages. template \"\" The template to use. The choices are moq, mockery, or a file path provided by file://path/to/file.txt. template-data {} A map[string]any that provides arbitrary options to the template. Each template will have a different set of accepted keys. Refer to each template's documentation for more details."},{"location":"configuration/#templates","title":"Templates","text":"Parameters marked as being templated have access to a number of template variables and functions through the Go text/template system.
The variables provided are specified in the config.Data struct.
All of the functions defined in StringManipulationFuncs are available to templated parameters.
The configuration applied to a specific mocked interface is merged according to the following precedence (in increasing priority):
.mockery.yaml.mockery.yaml.mockery.yamlIf a parameter is named enable-feature and we want a value of True, then these are the formats for each source:
--enable-feature=true Environment variable MOCKERY_ENABLE_FEATURE=True yaml enable-feature: True"},{"location":"faq/","title":"Frequently Asked Questions","text":""},{"location":"faq/#error-no-go-files-found-in-root-search-path","title":"error: no go files found in root search path","text":"When using the packages feature, recursive: true and you have specified a package that contains no *.go files, mockery is unable to determine the on-disk location of the package in order to continue the recursive package search. This appears to be a limitation of the golang.org/x/tools/go/packages package that is used to parse package metadata.
The solution is to create a .go file in the package's path and add a package [name] directive at the top. It doesn't matter what the file is called. This allows mockery to properly read package metadata.
Discussion
"},{"location":"faq/#internal-error-package-without-types-was-imported","title":"internal error: package without types was imported","text":"https://github.com/vektra/mockery/issues/475
This issue indicates that you have attempted to use package in your dependency tree (whether direct or indirect) that uses Go language semantics that your currently-running Go version does not support. The solution:
go clean -modcacheAdditionally, this issue only happens when compiling mockery from source, such as with go install. Our docs recommend not to use go install as the success of your build depends on the compatibility of your Go version with the semantics in use. You would not encounter this issue if using one of the installation methods that install pre-built binaries, like downloading the .tar.gz binaries, or through brew install.
There might be instances where you want a mock to return different values on successive calls that provide the same arguments. For example, we might want to test this behavior:
Go// Return \"foo\" on the first call\ngetter := NewGetter()\nassert(t, \"foo\", getter.Get(\"key\"))\n\n// Return \"bar\" on the second call\nassert(t, \"bar\", getter.Get(\"key\"))\nThis can be done by using the .Once() method on the mock call expectation:
mockGetter := NewMockGetter(t)\nmockGetter.EXPECT().Get(mock.anything).Return(\"foo\").Once()\nmockGetter.EXPECT().Get(mock.anything).Return(\"bar\").Once()\nOr you can identify an arbitrary number of times each value should be returned:
GomockGetter := NewMockGetter(t)\nmockGetter.EXPECT().Get(mock.anything).Return(\"foo\").Times(4)\nmockGetter.EXPECT().Get(mock.anything).Return(\"bar\").Times(2)\nNote that with proper Go support in your IDE, all the available methods are self-documented in autocompletion help contexts.
"},{"location":"faq/#variadic-arguments","title":"Variadic Arguments","text":"Consider if we have a function func Bar(message ...string) error. A typical assertion might look like this:
func TestFoo(t *testing.T) {\n m := NewMockFoo(t)\n m.On(\"Bar\", \"hello\", \"world\").Return(nil)\nWe might also want to make an assertion that says \"any number of variadic arguments\":
Gom.On(\"Bar\", mock.Anything).Return(nil)\nHowever, what we've given to mockery is ambiguous because it is impossible to distinguish between these two intentions:
This is fixed in #359 where you can provide unroll-variadic: False to get back to the old behavior. Thus, if you want to assert (1), you can then do:
m.On(\"Bar\", mock.Anything).Return(nil)\nIf you want to assert (2), you must set unroll-variadic: True. Then this assertion's intention will be modified to mean the second case:
m.On(\"Bar\", mock.Anything).Return(nil)\nAn upstream patch to testify is currently underway to allow passing mock.Anything directly to the variadic slice: https://github.com/stretchr/testify/pull/1348
If this is merged, it would become possible to describe the above two cases respectively:
Go// case 1\nm.On(\"Bar\", mock.Anything).Return(nil)\n// case 2\nm.On(\"Bar\", []interface{}{mock.Anything}).Return(nil)\nReferences:
The versioning in this project applies only to the behavior of the mockery binary itself. This project explicitly does not promise a stable internal API, but rather a stable executable. The versioning applies to the following:
What the version does not track:
go get-ing mockery with new or old versions of Go.main","text":"When your interfaces are in the main package, you should supply the --inpackage flag. This will generate mocks in the same package as the target code, avoiding import issues.
MOCKERY_VERSION environment variable is set","text":"This issue was first highlighted in this GitHub issue.
mockery uses the viper package for configuration mapping and parsing. Viper is set to automatically search for all config variables specified in its config struct. One of the config variables is named version, which gets mapped to an environment variable called MOCKERY_VERSION. If you set this environment variable, mockery attempts to parse it into the version bool config.
This is an adverse effect of how our config parsing is set up. The solution is to rename your environment variable to something other than MOCKERY_VERSION.
Visit the releases page to download one of the pre-built binaries for your platform.
"},{"location":"installation/#go-install","title":"go install","text":"Supported, but not recommended: see wiki page and related discussions.
Warning
Do not use @latest as this will pull from the latest, potentially untagged, commit on master.
Use the Docker image
Text Onlydocker pull vektra/mockery\nGenerate all the mocks for your project:
Text Onlydocker run -v \"$PWD\":/src -w /src vektra/mockery --all\nInstall through brew
Text Onlybrew install mockery\nbrew upgrade mockery\nThe replace-type: parameter allows you to replace a type in the generated mocks with another type. Take for example the following interface:
package replace_type\n\nimport (\n \"github.com/vektra/mockery/v3/internal/fixtures/example_project/replace_type/rti/rt1\"\n \"github.com/vektra/mockery/v3/internal/fixtures/example_project/replace_type/rti/rt2\"\n)\n\ntype RType interface {\n Replace1(f rt1.RType1)\n}\nYou can selectively replace the rt1.RType1 with a new type if so desired. For example:
replace-type:\n github.com/vektra/mockery/v3/internal/fixtures/example_project/replace_type/rti/rt1:\n RType1:\n pkg-path: github.com/vektra/mockery/v3/internal/fixtures/example_project/replace_type/rti/rt2\n type-name: RType2\nThe mock will now replace all instances of rt1.RType1 with rt2.RType2. You can see the before and after of mockery-style mocks:
// Replace2 provides a mock function for the type RTypeReplaced1\nfunc (_mock *RTypeReplaced1) Replace1(f rt1.RType1) {\n _mock.Called(f)\n return\n}\n// Replace2 provides a mock function for the type RTypeReplaced1\nfunc (_mock *RTypeReplaced1) Replace1(f rt2.RType2) {\n _mock.Called(f)\n return\n}\nThis parameter is useful if you need to need to work around packages that use internal types. Take for example the situation found here, noted by RangelReale.
"},{"location":"running/","title":"Running","text":"If your .mockery.yaml file has been populated with the packages and interfaces you want mocked, mockery can be run with no arguments. Take for example how the mockery project itself is configured:
quiet: False\nkeeptree: True\ndisable-version-string: True\nwith-expecter: True\nmockname: \"{{.InterfaceName}}\"\nfilename: \"{{.MockName}}.go\"\noutpkg: mocks\npackages:\n github.com/vektra/mockery/v3/pkg:\n interfaces:\n TypesPackage:\n# Lots more config...\nFrom anywhere within your repo, you can simply call mockery once, and it will find your config either by respecting the config path you gave it, or by searching upwards from the current working directory.
mockery\n08 Jul 23 01:40 EDT INF Starting mockery dry-run=false version=v2.31.0\n08 Jul 23 01:40 EDT INF Using config: /Users/landonclipp/git/LandonTClipp/mockery/.mockery.yaml dry-run=false version=v2.31.0\nCommand line arguments
It is valid to specify arguments from the command line. The configuration precedence is specified in the Configuration docs.
"},{"location":"v3/","title":"v3 Release","text":"Mockery releases version 3 of the project that provides a number of high-profile benefits over v2:
matryer-style templates. The https://github.com/matryer/moq project is being folded into mockery to combine the speed and configuration flexibility of mockery with the simplicity of moq-style mocks.Construction
This section is under construction.
"},{"location":"template/","title":"Templates","text":"Mockery, in its essence, renders templates. This project provides a number of pre-curated templates that you can select with the template: config parameter.
template: \"testify\"","text":"testify templates generate powerful, testify-based mock objects. They allow you to create expectations using argument-to-return-value matching logic.
package test\n\nimport (\n \"testing\"\n\n \"github.com/stretchr/testify/assert\"\n)\n\nfunc TestRequesterMock(t *testing.T) {\n m := NewMockRequester(t)\n m.EXPECT().Get(\"foo\").Return(\"bar\", nil).Once()\n retString, err := m.Get(\"foo\")\n assert.NoError(t, err)\n assert.Equal(t, retString, \"bar\")\n}\ntemplate: \"matryer\"","text":"matryer templates draw from the mocks generated from the project at https://github.com/matryer/moq. This project was folded into mockery, and thus moq-style mocks can be natively generated from within mockery.
Mocks generated using this template allow you to define precise functions to be run. Example:
Gofunc TestRequesterMoq(t *testing.T) {\n m := &MoqRequester{\n GetFunc: func(path string) (string, error) {\n fmt.Printf(\"Go path: %s\\n\", path)\n return path + \"/foo\", nil\n },\n }\n result, err := m.Get(\"/path\")\n assert.NoError(t, err)\n assert.Equal(t, \"/path/foo\", result)\n}\ntemplate: \"file://","text":"You may also provide mockery a path to your own file using the file:// protocol specifier. The string after file:// will be the relative or absolute path of your template.
The templates are rendered with the data as shown in the section below.
You can see examples of how the mockery project utilizes the template system to generate the different mock styles:
moq.templmockery.templTemplate files have both StringManipulationFuncs and TemplateMockFuncs available as functions.
The template is supplied with the template.Data struct. Some attributes return types such as template.MockData and template.Package which themselves contain methods that may also be called.
.mockery.ymlmocks_moq.goExample Usage Gopackage test\n\ntype Requester interface {\n Get(path string) (string, error)\n}\ntemplate: matryer\npackages:\n github.com/vektra/mockery/v3/pkg/fixtures:\n config:\n dir: \"{{.InterfaceDir}}\"\n filename: \"mocks_moq.go\"\n pkgname: \"test\"\n mockname: \"Moq{{.InterfaceName}}\"\n interfaces:\n Requester:\n// Code generated by mockery; DO NOT EDIT.\n// github.com/vektra/mockery\n\npackage test\n\nimport (\n \"sync\"\n)\n\n// Ensure, that MoqRequester does implement Requester.\n// If this is not the case, regenerate this file with moq.\nvar _ Requester = &MoqRequester{}\n\n// MoqRequester is a mock implementation of Requester.\n//\n// func TestSomethingThatUsesRequester(t *testing.T) {\n//\n// // make and configure a mocked Requester\n// mockedRequester := &MoqRequester{\n// GetFunc: func(path string) (string, error) {\n// panic(\"mock out the Get method\")\n// },\n// }\n//\n// // use mockedRequester in code that requires Requester\n// // and then make assertions.\n//\n// }\ntype MoqRequester struct {\n // GetFunc mocks the Get method.\n GetFunc func(path string) (string, error)\n\n // calls tracks calls to the methods.\n calls struct {\n // Get holds details about calls to the Get method.\n Get []struct {\n // Path is the path argument value.\n Path string\n }\n }\n lockGet sync.RWMutex\n}\n\n// Get calls GetFunc.\nfunc (mock *MoqRequester) Get(path string) (string, error) {\n // ...\n}\n\n// GetCalls gets all the calls that were made to Get.\n// Check the length with:\n//\n// len(mockedRequester.GetCalls())\nfunc (mock *MoqRequester) GetCalls() []struct {\n Path string\n} {\n // ...\n}\nfunc TestRequesterMoq(t *testing.T) {\n m := &MoqRequester{\n GetFunc: func(path string) (string, error) {\n fmt.Printf(\"Go path: %s\\n\", path)\n return path + \"/foo\", nil\n },\n }\n result, err := m.Get(\"/path\")\n assert.NoError(t, err)\n assert.Equal(t, \"/path/foo\", result)\n}\nMoq-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.
"},{"location":"template/matryer/#template-data","title":"template-data","text":"moq accepts the following template-data: keys:
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 \"\" 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. with-resets bool Generates methods that allow resetting calls made to the mocks."},{"location":"template/testify/","title":"Mockery","text":"Features for template: testify.
Choosing this template will render a traditional \"mockery-style\" template. The section below shows what will be rendered for the given interface.
"},{"location":"template/testify/#description","title":"Description","text":"Interface.mockery.ymlmocks.goExample Usage Gopackage test\n\ntype Requester interface {\n Get(path string) (string, error)\n}\ntemplate: testify\npackages:\n github.com/vektra/mockery/v3/pkg/fixtures:\n config:\n dir: \"{{.InterfaceDir}}\"\n filename: \"mocks.go\"\n pkgname: \"test\"\n mockname: \"Mock{{.InterfaceName}}\"\n interfaces:\n Requester:\n// Code generated by mockery; DO NOT EDIT.\n// github.com/vektra/mockery\n\npackage test\n\nimport (\n mock \"github.com/stretchr/testify/mock\"\n)\n\n\n// NewRequester creates a new instance of Requester. It also registers a testing interface on the mock and a cleanup function to assert the mocks expectations.\n// The first argument is typically a *testing.T value.\nfunc NewRequester (t interface {\n mock.TestingT\n Cleanup(func())\n}) *Requester {\n // ...\n}\n\n\n// Requester is an autogenerated mock type for the Requester type\ntype Requester struct {\n mock.Mock\n}\n\ntype Requester_Expecter struct {\n mock *mock.Mock\n}\n\nfunc (_m *Requester) EXPECT() *Requester_Expecter {\n // ...\n}\n\n\n\n// Get provides a mock function for the type Requester\nfunc (_mock *Requester) Get(path string) (string, error) {\n // ...\n}\n\n\n\n// Requester_Get_Call is a *mock.Call that shadows Run/Return methods with type explicit version for method 'Get'\ntype Requester_Get_Call struct {\n *mock.Call\n}\n\n\n\n// Get is a helper method to define mock.On call\n// - path\nfunc (_e *Requester_Expecter) Get(path interface{}, ) *Requester_Get_Call {\n // ...\n}\n\nfunc (_c *Requester_Get_Call) Run(run func(path string)) *Requester_Get_Call {\n // ...\n}\n\nfunc (_c *Requester_Get_Call) Return(s string, err error) *Requester_Get_Call {\n // ...\n}\n\nfunc (_c *Requester_Get_Call) RunAndReturn(run func(path string)(string, error)) *Requester_Get_Call {\n // ...\n}\npackage test\n\nimport (\n \"testing\"\n\n \"github.com/stretchr/testify/assert\"\n)\n\nfunc TestRequesterMock(t *testing.T) {\n m := NewMockRequester(t)\n m.EXPECT().Get(\"foo\").Return(\"bar\", nil).Once()\n retString, err := m.Get(\"foo\")\n assert.NoError(t, err)\n assert.Equal(t, retString, \"bar\")\n}\nAs you can see, this mock utilizes github.com/stretchr/testify under the hood and registers call expectations with testify. When the mock receives a call to Get(), it retrieves the expected value from testify to be returned.
This style of mock also has other interesting methods:
Run()RunAndReturn()github.com/stretchr/testify/mock.Mock Run a side effect when the argument matches.
Gofunc TestRequesterMockRun(t *testing.T) {\n m := NewMockRequester(t)\n m.EXPECT().Get(mock.Anything).Return(\"\", nil)\n m.EXPECT().Get(mock.Anything).Run(func(path string) {\n fmt.Printf(\"Side effect! Argument is: %s\", path)\n })\n retString, err := m.Get(\"hello\")\n assert.NoError(t, err)\n assert.Equal(t, retString, \"\")\n}\nRun a function to perform side-effects, and return the result of the function.
Gofunc TestRequesterMockRunAndReturn(t *testing.T) {\n m := NewMockRequester(t)\n m.EXPECT().Get(mock.Anything).RunAndReturn(func(path string) (string, error) {\n return path + \" world\", nil\n })\n retString, err := m.Get(\"hello\")\n assert.NoError(t, err)\n assert.Equal(t, retString, \"hello world\")\n}\nBecause the mock embeds the testify Mock object, you can all any methods on that as well.
func TestRequesterMockTestifyEmbed(t *testing.T) {\n m := NewMockRequester(t)\n m.EXPECT().Get(mock.Anything).Return(\"\", nil).Twice()\n m.Get(\"hello\")\n m.Get(\"world\")\n assert.Equal(t, len(m.Mock.Calls), 2)\n}\ntemplate-data","text":"key type description 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 \"\" Set the build tags of the generated mocks. Read more about the format. unroll-variadic bool If set to unroll-variadic: true, will expand the variadic argument to testify using the ... syntax. See notes for more details."},{"location":"template/testify/#features","title":"Features","text":""},{"location":"template/testify/#replace-types","title":"Replace Types","text":"v2.23.0
The replace-type parameter allows adding a list of type replacements to be made in package and/or type names. This can help overcome issues like usage of type aliases that point to internal packages.
The format of the parameter is:
originalPackagePath.originalTypeName=newPackageName:newPackagePath.newTypeName
For example:
Bashmockery --replace-type github.com/vektra/mockery/v3/baz/internal/foo.InternalBaz=baz:github.com/vektra/mockery/v3/baz.Baz\nThis will replace any imported named \"github.com/vektra/mockery/v3/baz/internal/foo\" with baz \"github.com/vektra/mockery/v3/baz\". The alias is defined with : before the package name. Also, the InternalBaz type that comes from this package will be renamed to baz.Baz.
This next example fixes a common problem of type aliases that point to an internal package.
cloud.google.com/go/pubsub.Message is a type alias defined like this:
import (\n ipubsub \"cloud.google.com/go/internal/pubsub\"\n)\n\ntype Message = ipubsub.Message\nThe Go parser that mockery uses doesn't provide a way to detect this alias and sends the application the package and type name of the type in the internal package, which will not work.
We can use replace-type with only the package part to replace any import of cloud.google.com/go/internal/pubsub to cloud.google.com/go/pubsub. We don't need to change the alias or type name in this case, because they are pubsub and Message in both cases.
mockery --replace-type cloud.google.com/go/internal/pubsub=cloud.google.com/go/pubsub\nOriginal source:
Goimport (\n \"cloud.google.com/go/pubsub\"\n)\n\ntype Handler struct {\n HandleMessage(m pubsub.Message) error\n}\nInvalid mock generated without this parameter (points to an internal folder):
import (\n mock \"github.com/stretchr/testify/mock\"\n\n pubsub \"cloud.google.com/go/internal/pubsub\"\n)\n\nfunc (_m *Handler) HandleMessage(m pubsub.Message) error {\n // ...\n return nil\n}\nCorrect mock generated with this parameter.
Goimport (\n mock \"github.com/stretchr/testify/mock\"\n\n pubsub \"cloud.google.com/go/pubsub\"\n)\n\nfunc (_m *Handler) HandleMessage(m pubsub.Message) error {\n // ...\n return nil\n}\nGeneric type constraints can also be replaced by targeting the changed parameter with the square bracket notation on the left-hand side.
Bashmockery --replace-type github.com/vektra/mockery/v3/baz/internal/foo.InternalBaz[T]=github.com/vektra/mockery/v3/baz.Baz\nFor example:
Gotype InternalBaz[T any] struct{}\n\nfunc (*InternalBaz[T]) Foo() T {}\n\n// Becomes\ntype InternalBaz[T baz.Baz] struct{}\n\nfunc (*InternalBaz[T]) Foo() T {}\nIf a type constraint needs to be removed and replaced with a type, target the constraint with square brackets and include a '-' in front to have it removed.
Bashmockery --replace-type github.com/vektra/mockery/v3/baz/internal/foo.InternalBaz[-T]=github.com/vektra/mockery/v3/baz.Baz\nFor example:
Gotype InternalBaz[T any] struct{}\n\nfunc (*InternalBaz[T]) Foo() T {}\n\n// Becomes\ntype InternalBaz struct{}\n\nfunc (*InternalBaz) Foo() baz.Baz {}\nWhen replacing a generic constraint, you can replace the type with a pointer by adding a '*' before the output type name.
Bashmockery --replace-type github.com/vektra/mockery/v3/baz/internal/foo.InternalBaz[-T]=github.com/vektra/mockery/v3/baz.*Baz\nFor example:
Gotype InternalBaz[T any] struct{}\n\nfunc (*InternalBaz[T]) Foo() T {}\n\n// Becomes\ntype InternalBaz struct{}\n\nfunc (*InternalBaz) Foo() *baz.Baz {}\nv2.11.0
All mock objects have constructor functions. These constructors do basic test setup so that the expectations you set in the code are asserted before the test exits.
Previously something like this would need to be done: Go
factory := &mocks.Factory{}\nfactory.Test(t) // so that mock does not panic when a method is unexpected\ndefer factory.AssertExpectations(t)\nInstead, you may simply use the constructor: Go
factory := mocks.NewFactory(t)\nThe constructor sets up common functionalities automatically
AssertExpectations method is registered to be called at the end of the tests via t.Cleanup() method.mock.Mock so that tests don't panic when a call on the mock is unexpected. v2.10.0 \u00b7 with-expecter: True
Mockery now supports an \"expecter\" struct, which allows your tests to use type-safe methods to generate call expectations. When enabled through the with-expecter: True mockery configuration, you can enter into the expecter interface by simply calling .EXPECT() on your mock object.
For example, given an interface such as Go
type Requester interface {\n Get(path string) (string, error)\n}\nYou can use the expecter interface as such: Go
requesterMock := mocks.NewRequester(t)\nrequesterMock.EXPECT().Get(\"some path\").Return(\"result\", nil)\nA RunAndReturn method is also available on the expecter struct that allows you to dynamically set a return value based on the input to the mock's call.
requesterMock.EXPECT().\n Get(mock.Anything).\n RunAndReturn(func(path string) (string, error) {\n fmt.Println(path, \"was called\")\n return (\"result for \" + path), nil\n })\nNote
Note that the types of the arguments on the EXPECT methods are interface{}, not the actual type of your interface. The reason for this is that you may want to pass mock.Any as an argument, which means that the argument you pass may be an arbitrary type. The types are still provided in the expecter method docstrings.
v2.20.0
Return Value Providers can be used one of two ways. You may either define a single function with the exact same signature (number and type of input and return parameters) and pass that as a single value to Return, or you may pass multiple values to Return (one for each return parameter of the mocked function.) If you are using the second form, for each of the return values of the mocked function, Return needs a function which takes the same arguments as the mocked function, and returns one of the return values. For example, if the return argument signature of passthrough in the above example was instead (string, error) in the interface, Return would also need a second function argument to define the error value:
type Proxy interface {\n passthrough(ctx context.Context, s string) (string, error)\n}\nFirst form:
GoproxyMock := mocks.NewProxy(t)\nproxyMock.On(\"passthrough\", mock.AnythingOfType(\"context.Context\"), mock.AnythingOfType(\"string\")).\nReturn(\n func(ctx context.Context, s string) (string, error) {\n return s, nil\n }\n)\nSecond form:
GoproxyMock := mocks.NewProxy(t)\nproxyMock.On(\"passthrough\", mock.AnythingOfType(\"context.Context\"), mock.AnythingOfType(\"string\")).\nReturn(\n func(ctx context.Context, s string) string {\n return s\n },\n func(ctx context.Context, s string) error {\n return nil\n },\n)\nAlpha Test
Mockery v3 is currently in alpha and should not be used for production.
Mockery is a project that creates mock implementations of Golang interfaces. It inspects source code and generates implementations of the interface that aid in testing.
In addition to providing a number of different styles of mocks, mockery also allows users to provide their own template files that will then be rendered using a set of template data, methods, and functions that provide comprehensive typing information about the Go interface in question.
"},{"location":"#why-mockery","title":"Why mockery?","text":"
When you have an interface like this:
db.gotype DB interface {\n Get(val string) string\n}\nand a function that takes this interface:
db_getter.gofunc getFromDB(db DB) string {\n return db.Get(\"ice cream\")\n}\nWe can use simple configuration to generate a mock implementation for the interface:
.mockery.yamlpackages:\n github.com/org/repo:\n interfaces:\n DB:\n$ mockery\n05 Mar 23 21:49 CST INF Starting mockery dry-run=false version=v3.0.0\n05 Mar 23 21:49 CST INF Using config: .mockery.yaml dry-run=false version=v3.0.0\n05 Mar 23 21:49 CST INF Generating mock dry-run=false interface=DB qualified-name=github.com/org/repo version=v3.0.0\nWe can then use the mock object in a test:
db_getter_test.goimport (\n \"testing\"\n\n \"github.com/stretchr/testify/assert\"\n)\n\nfunc Test_getFromDB(t *testing.T) {\n mockDB := NewMockDB(t)\n mockDB.EXPECT().Get(\"ice cream\").Return(\"chocolate\").Once()\n flavor := getFromDB(mockDB)\n assert.Equal(t, \"chocolate\", flavor)\n}\n//go:generate commands.Get Started
"},{"location":"configuration/","title":"Configuration","text":""},{"location":"configuration/#example","title":"Example","text":"All configuration is specified in a .mockery.yml file. An example config file may look like this:
all: False\ntemplate-data:\n boilerplate-file: ./path/to/boilerplate.txt\ntemplate: mockery\npackages:\n github.com/vektra/example:\n config:\n # Make use of the template variables to place the mock in the same\n # directory as the original interface.\n dir: \"{{.InterfaceDir}}\"\n filename: \"mocks_test.go\"\n outpkg: \"{{.PackageName}}_test\"\n mockname: \"Mock{{.InterfaceName}}\"\n interfaces:\n Foo:\n Bar:\n config:\n # Make it unexported instead\n mockname: \"mock{{.InterfaceName}}\"\n Baz:\n # Create two mock implementations of Baz with different names.\n configs:\n - filename: \"mocks_baz_one_test.go\"\n mockname: \"MockBazOne\"\n - filename: \"mocks_baz_two_test.go\"\n mockname: \"MockBazTwo\"\n io:\n config:\n dir: path/to/io/mocks\n filename: \"mocks_io.go\"\nThese are the highlights of the config scheme:
template parameter.An output file may contain multiple mocks, but the only rule is that all the mocks in the file must come from the same package. Because of this, mocks for different packages must go in different files.
"},{"location":"configuration/#parameter-descriptions","title":"Parameter Descriptions","text":"name templated default descriptionall false Generate all interfaces for the specified packages. _anchors {} Unused by mockery, but allowed in the config schema so that you may define arbitrary yaml anchors. config \"\" Set the location of the mockery config file. dir \"mocks/{{.SrcPackagePath}}\" The directory where the mock file will be outputted to. exclude-subpkg-regex [] A list of regular expressions that denote which subpackages should be excluded when recursive: true exclude-regex \"\" When set along with include-regex, then interfaces which match include-regex but also match exclude-regex will not be generated. If all is set, or if include-regex is not set, then exclude-regex has no effect. filename \"mock_{{.InterfaceName}}.go\" The name of the file the mock will reside in. force-file-write false When set to force-file-write: true, mockery will forcibly overwrite any existing files. formatter \"goimports\" The formatter to use on the rendered template. Choices are: gofmt, goimports, noop. include-regex \"\" When set, only interface names that match the expression will be generated. This setting is ignored if all: True is specified in the configuration. To further refine the interfaces generated, use exclude-regex. log-level \"info\" Set the level of the logger mockname \"Mock{{.InterfaceName}}\" The name of the generated mock. outpkg \"{{.PackageName}}\" Use outpkg to specify the package name of the generated mocks. packages null A dictionary containing configuration describing the packages and interfaces to generate mocks for. pkgname \"{{.SrcPackageName}}\" | The#!go package name` given to the generated mock files. recursive false When set to true on a particular package, mockery will recursively search for all sub-packages and inject those packages into the config map. replace-type {} Use this parameter to specify type replacements. tags \"\" A space-separated list of additional build tags to load packages. template \"\" The template to use. The choices are moq, mockery, or a file path provided by file://path/to/file.txt. template-data {} A map[string]any that provides arbitrary options to the template. Each template will have a different set of accepted keys. Refer to each template's documentation for more details."},{"location":"configuration/#templates","title":"Templates","text":"Parameters marked as being templated have access to a number of template variables and functions through the Go text/template system.
The variables provided are specified in the config.Data struct.
All of the functions defined in StringManipulationFuncs are available to templated parameters.
The configuration applied to a specific mocked interface is merged according to the following precedence (in increasing priority):
.mockery.yaml.mockery.yaml.mockery.yamlIf a parameter is named enable-feature and we want a value of True, then these are the formats for each source:
--enable-feature=true Environment variable MOCKERY_ENABLE_FEATURE=True yaml enable-feature: True"},{"location":"faq/","title":"Frequently Asked Questions","text":""},{"location":"faq/#error-no-go-files-found-in-root-search-path","title":"error: no go files found in root search path","text":"When using the packages feature, recursive: true and you have specified a package that contains no *.go files, mockery is unable to determine the on-disk location of the package in order to continue the recursive package search. This appears to be a limitation of the golang.org/x/tools/go/packages package that is used to parse package metadata.
The solution is to create a .go file in the package's path and add a package [name] directive at the top. It doesn't matter what the file is called. This allows mockery to properly read package metadata.
Discussion
"},{"location":"faq/#internal-error-package-without-types-was-imported","title":"internal error: package without types was imported","text":"https://github.com/vektra/mockery/issues/475
This issue indicates that you have attempted to use package in your dependency tree (whether direct or indirect) that uses Go language semantics that your currently-running Go version does not support. The solution:
go clean -modcacheAdditionally, this issue only happens when compiling mockery from source, such as with go install. Our docs recommend not to use go install as the success of your build depends on the compatibility of your Go version with the semantics in use. You would not encounter this issue if using one of the installation methods that install pre-built binaries, like downloading the .tar.gz binaries, or through brew install.
The mockery project follows the standard Semantic Versioning Semantics. The versioning applies to the following areas:
template: \"file://\".Mockery is not meant to be used as an imported library. Importing mockery code in external modules is not supported.
"},{"location":"faq/#mocking-interfaces-in-main","title":"Mocking interfaces inmain","text":"When your interfaces are in the main package, you should supply the --inpackage flag. This will generate mocks in the same package as the target code, avoiding import issues.
MOCKERY_VERSION environment variable is set","text":"This issue was first highlighted in this GitHub issue.
mockery uses the viper package for configuration mapping and parsing. Viper is set to automatically search for all config variables specified in its config struct. One of the config variables is named version, which gets mapped to an environment variable called MOCKERY_VERSION. If you set this environment variable, mockery attempts to parse it into the version bool config.
This is an adverse effect of how our config parsing is set up. The solution is to rename your environment variable to something other than MOCKERY_VERSION.
Visit the releases page to download one of the pre-built binaries for your platform.
"},{"location":"installation/#go-install","title":"go install","text":"Supported, but not recommended: see wiki page and related discussions.
Warning
Do not use @latest as this will pull from the latest, potentially untagged, commit on master.
Use the Docker image
Text Onlydocker pull vektra/mockery\nGenerate all the mocks for your project:
Text Onlydocker run -v \"$PWD\":/src -w /src vektra/mockery --all\nInstall through brew
Text Onlybrew install mockery\nbrew upgrade mockery\nThe replace-type: parameter allows you to replace a type in the generated mocks with another type. Take for example the following interface:
package replace_type\n\nimport (\n \"github.com/vektra/mockery/v3/internal/fixtures/example_project/replace_type/rti/rt1\"\n \"github.com/vektra/mockery/v3/internal/fixtures/example_project/replace_type/rti/rt2\"\n)\n\ntype RType interface {\n Replace1(f rt1.RType1)\n}\nYou can selectively replace the rt1.RType1 with a new type if so desired. For example:
replace-type:\n github.com/vektra/mockery/v3/internal/fixtures/example_project/replace_type/rti/rt1:\n RType1:\n pkg-path: github.com/vektra/mockery/v3/internal/fixtures/example_project/replace_type/rti/rt2\n type-name: RType2\nThe mock will now replace all instances of rt1.RType1 with rt2.RType2. You can see the before and after of mockery-style mocks:
// Replace2 provides a mock function for the type RTypeReplaced1\nfunc (_mock *RTypeReplaced1) Replace1(f rt1.RType1) {\n _mock.Called(f)\n return\n}\n// Replace2 provides a mock function for the type RTypeReplaced1\nfunc (_mock *RTypeReplaced1) Replace1(f rt2.RType2) {\n _mock.Called(f)\n return\n}\nThis parameter is useful if you need to need to work around packages that use internal types. Take for example the situation found here, noted by RangelReale.
"},{"location":"running/","title":"Running","text":"If your .mockery.yaml file has been populated with the packages and interfaces you want mocked, mockery can be run with no arguments. Take for example how the mockery project itself is configured:
quiet: False\nkeeptree: True\ndisable-version-string: True\nwith-expecter: True\nmockname: \"{{.InterfaceName}}\"\nfilename: \"{{.MockName}}.go\"\noutpkg: mocks\npackages:\n github.com/vektra/mockery/v3/pkg:\n interfaces:\n TypesPackage:\n# Lots more config...\nFrom anywhere within your repo, you can simply call mockery once, and it will find your config either by respecting the config path you gave it, or by searching upwards from the current working directory.
mockery\n08 Jul 23 01:40 EDT INF Starting mockery dry-run=false version=v2.31.0\n08 Jul 23 01:40 EDT INF Using config: /Users/landonclipp/git/LandonTClipp/mockery/.mockery.yaml dry-run=false version=v2.31.0\nCommand line arguments
It is valid to specify arguments from the command line. The configuration precedence is specified in the Configuration docs.
"},{"location":"v3/","title":"v3 Release","text":"Mockery releases version 3 of the project that provides a number of high-profile benefits over v2:
matryer-style templates. The https://github.com/matryer/moq project is being subsumed into mockery to combine the speed and configuration flexibility of mockery with the simplicity of moq-style mocks.In v3, mockery is capable of producing two styles of mocks. In v3, the mockery-style mocks are called testify and can be used by setting template: testify. The shape of the mocks should be identical (minus the now-required expecter methods) and should not require any changes to existing tests using testify-style mocks.(1)
testify-style mocks have breaking changes, please submit an issue on Github.Mockery v2 has explicitly deprecated a number of variables. These deprecations can be found here: https://vektra.github.io/mockery/latest-v2/deprecations/. Mockery logs warnings such as:
20 Jan 25 15:53 CST WRN DEPRECATION: disable-version-string will be permanently set to True in v3 deprecation-name=disable-version-string url=https://vektra.github.io/mockery/v0.0/deprecations/#disable-version-string version=v0.0.0-dev\n20 Jan 25 15:53 CST WRN DEPRECATION: issue-845-fix must be set to True to remove this warning. Visit the link for more details. deprecation-name=issue-845-fix url=https://vektra.github.io/mockery/v0.0/deprecations/#issue-845-fix version=v0.0.0-dev\n20 Jan 25 15:53 CST WRN DEPRECATION: resolve-type-alias will be permanently set to False in v3. Please modify your config to set the parameter to False. deprecation-name=resolve-type-alias url=https://vektra.github.io/mockery/v0.0/deprecations/#resolve-type-alias version=v0.0.0-dev\n20 Jan 25 15:53 CST WRN DEPRECATION: with-expecter will be permanently set to True in v3 deprecation-name=with-expecter url=https://vektra.github.io/mockery/v0.0/deprecations/#with-expecter version=v0.0.0-dev\nThese warnings provide doc URLs that indicate how to fix the warning to prepare for the v3 release. While we provide these warnings on a best-effort basis, they are unlikely to be comprehensive due to the large number of changes that v3 introduces. Please submit an issue on Github if you notice a missing deprecation warning that would be useful to have.
"},{"location":"v3/#layouts","title":"Layouts","text":"In v2, mockery defaulted to placing mocks in a separate mocks/ directory as shown here. In v3, mockery will by default place mocks adjacent to the mocked interface.
It is still possible to place mocks in a separate directory by making use of the template variables and functions available to the configuration parameters.
"},{"location":"v3/#function-mocks","title":"Function Mocks","text":"Mockery v2 allowed generating mocks for function types. v3 no longer does this as it provided little benefit for users.
"},{"location":"v3/#parameters","title":"Parameters","text":""},{"location":"v3/#inpackage-true","title":"inpackage: True","text":"Mockery v2 has an inpackage parameter that informed mockery when a mock was being generated in the same package as the original interface. In v3, this parameter has been removed as mockery is now able to detect when the mock is placed in the same package.
keeptree: True","text":"Mockery v2 provided a keeptree parameter that was deprecated and used only in the pre-packages config schema. This parameter has no use in v3 and has been removed.
replace-type:","text":"The replace-type: parameter has an updated schema. In v2, users provided a list of strings, where each string needed to confirm to a specific format that was parsed at runtime. In v3, the schema is more explicit to make it simpler.
struct-name:","text":"The struct-name parameter has been replaced with mock-name.
resolve-alias:","text":"In v2, resolve-alias was set to True by default to retain backwards compatability. In v3, this is set to False by default.
with-expecter:","text":"In v3, this parameter has been removed. testify-style mocks will always generate expecter methods.
unroll-variadic:","text":"This parameter has been moved under the template-data: parameter. Parameters that apply only to specific templates are not expressed in the top-level schema and are instead passed through the schemaless template-data: map.
exclude:","text":"This parameter in v2 was renamed to exclude-subpkg-regex:.
Mockery, in its essence, renders templates. This project provides a number of pre-curated templates that you can select with the template: config parameter.
template: \"testify\"","text":"testify templates generate powerful, testify-based mock objects. They allow you to create expectations using argument-to-return-value matching logic.
package test\n\nimport (\n \"testing\"\n\n \"github.com/stretchr/testify/assert\"\n)\n\nfunc TestRequesterMock(t *testing.T) {\n m := NewMockRequester(t)\n m.EXPECT().Get(\"foo\").Return(\"bar\", nil).Once()\n retString, err := m.Get(\"foo\")\n assert.NoError(t, err)\n assert.Equal(t, retString, \"bar\")\n}\ntemplate: \"matryer\"","text":"matryer templates draw from the mocks generated from the project at https://github.com/matryer/moq. This project was folded into mockery, and thus moq-style mocks can be natively generated from within mockery.
Mocks generated using this template allow you to define precise functions to be run. Example:
Gofunc TestRequesterMoq(t *testing.T) {\n m := &MoqRequester{\n GetFunc: func(path string) (string, error) {\n fmt.Printf(\"Go path: %s\\n\", path)\n return path + \"/foo\", nil\n },\n }\n result, err := m.Get(\"/path\")\n assert.NoError(t, err)\n assert.Equal(t, \"/path/foo\", result)\n}\ntemplate: \"file://","text":"You may also provide mockery a path to your own file using the file:// protocol specifier. The string after file:// will be the relative or absolute path of your template.
The templates are rendered with the data as shown in the section below.
You can see examples of how the mockery project utilizes the template system to generate the different mock styles:
moq.templmockery.templTemplate files have both StringManipulationFuncs and TemplateMockFuncs available as functions.
The template is supplied with the template.Data struct. Some attributes return types such as template.MockData and template.Package which themselves contain methods that may also be called.
.mockery.ymlmocks_moq.goExample Usage Gopackage test\n\ntype Requester interface {\n Get(path string) (string, error)\n}\ntemplate: matryer\npackages:\n github.com/vektra/mockery/v3/pkg/fixtures:\n config:\n dir: \"{{.InterfaceDir}}\"\n filename: \"mocks_moq.go\"\n pkgname: \"test\"\n mockname: \"Moq{{.InterfaceName}}\"\n interfaces:\n Requester:\n// Code generated by mockery; DO NOT EDIT.\n// github.com/vektra/mockery\n\npackage test\n\nimport (\n \"sync\"\n)\n\n// Ensure, that MoqRequester does implement Requester.\n// If this is not the case, regenerate this file with moq.\nvar _ Requester = &MoqRequester{}\n\n// MoqRequester is a mock implementation of Requester.\n//\n// func TestSomethingThatUsesRequester(t *testing.T) {\n//\n// // make and configure a mocked Requester\n// mockedRequester := &MoqRequester{\n// GetFunc: func(path string) (string, error) {\n// panic(\"mock out the Get method\")\n// },\n// }\n//\n// // use mockedRequester in code that requires Requester\n// // and then make assertions.\n//\n// }\ntype MoqRequester struct {\n // GetFunc mocks the Get method.\n GetFunc func(path string) (string, error)\n\n // calls tracks calls to the methods.\n calls struct {\n // Get holds details about calls to the Get method.\n Get []struct {\n // Path is the path argument value.\n Path string\n }\n }\n lockGet sync.RWMutex\n}\n\n// Get calls GetFunc.\nfunc (mock *MoqRequester) Get(path string) (string, error) {\n // ...\n}\n\n// GetCalls gets all the calls that were made to Get.\n// Check the length with:\n//\n// len(mockedRequester.GetCalls())\nfunc (mock *MoqRequester) GetCalls() []struct {\n Path string\n} {\n // ...\n}\nfunc TestRequesterMoq(t *testing.T) {\n m := &MoqRequester{\n GetFunc: func(path string) (string, error) {\n fmt.Printf(\"Go path: %s\\n\", path)\n return path + \"/foo\", nil\n },\n }\n result, err := m.Get(\"/path\")\n assert.NoError(t, err)\n assert.Equal(t, \"/path/foo\", result)\n}\nMoq-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.
"},{"location":"template/matryer/#template-data","title":"template-data","text":"moq accepts the following template-data: keys:
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 \"\" 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. with-resets bool Generates methods that allow resetting calls made to the mocks."},{"location":"template/testify/","title":"Mockery","text":"Features for template: testify.
Choosing this template will render a traditional \"mockery-style\" template. The section below shows what will be rendered for the given interface.
"},{"location":"template/testify/#description","title":"Description","text":"Interface.mockery.ymlmocks.goExample Usage Gopackage test\n\ntype Requester interface {\n Get(path string) (string, error)\n}\ntemplate: testify\npackages:\n github.com/vektra/mockery/v3/pkg/fixtures:\n config:\n dir: \"{{.InterfaceDir}}\"\n filename: \"mocks.go\"\n pkgname: \"test\"\n mockname: \"Mock{{.InterfaceName}}\"\n interfaces:\n Requester:\n// Code generated by mockery; DO NOT EDIT.\n// github.com/vektra/mockery\n\npackage test\n\nimport (\n mock \"github.com/stretchr/testify/mock\"\n)\n\n\n// NewRequester creates a new instance of Requester. It also registers a testing interface on the mock and a cleanup function to assert the mocks expectations.\n// The first argument is typically a *testing.T value.\nfunc NewRequester (t interface {\n mock.TestingT\n Cleanup(func())\n}) *Requester {\n // ...\n}\n\n\n// Requester is an autogenerated mock type for the Requester type\ntype Requester struct {\n mock.Mock\n}\n\ntype Requester_Expecter struct {\n mock *mock.Mock\n}\n\nfunc (_m *Requester) EXPECT() *Requester_Expecter {\n // ...\n}\n\n\n\n// Get provides a mock function for the type Requester\nfunc (_mock *Requester) Get(path string) (string, error) {\n // ...\n}\n\n\n\n// Requester_Get_Call is a *mock.Call that shadows Run/Return methods with type explicit version for method 'Get'\ntype Requester_Get_Call struct {\n *mock.Call\n}\n\n\n\n// Get is a helper method to define mock.On call\n// - path\nfunc (_e *Requester_Expecter) Get(path interface{}, ) *Requester_Get_Call {\n // ...\n}\n\nfunc (_c *Requester_Get_Call) Run(run func(path string)) *Requester_Get_Call {\n // ...\n}\n\nfunc (_c *Requester_Get_Call) Return(s string, err error) *Requester_Get_Call {\n // ...\n}\n\nfunc (_c *Requester_Get_Call) RunAndReturn(run func(path string)(string, error)) *Requester_Get_Call {\n // ...\n}\npackage test\n\nimport (\n \"testing\"\n\n \"github.com/stretchr/testify/assert\"\n)\n\nfunc TestRequesterMock(t *testing.T) {\n m := NewMockRequester(t)\n m.EXPECT().Get(\"foo\").Return(\"bar\", nil).Once()\n retString, err := m.Get(\"foo\")\n assert.NoError(t, err)\n assert.Equal(t, retString, \"bar\")\n}\nAs you can see, this mock utilizes github.com/stretchr/testify under the hood and registers call expectations with testify. When the mock receives a call to Get(), it retrieves the expected value from testify to be returned.
This style of mock also has other interesting methods:
Run()RunAndReturn()github.com/stretchr/testify/mock.Mock Run a side effect when the argument matches.
Gofunc TestRequesterMockRun(t *testing.T) {\n m := NewMockRequester(t)\n m.EXPECT().Get(mock.Anything).Return(\"\", nil)\n m.EXPECT().Get(mock.Anything).Run(func(path string) {\n fmt.Printf(\"Side effect! Argument is: %s\", path)\n })\n retString, err := m.Get(\"hello\")\n assert.NoError(t, err)\n assert.Equal(t, retString, \"\")\n}\nRun a function to perform side-effects, and return the result of the function.
Gofunc TestRequesterMockRunAndReturn(t *testing.T) {\n m := NewMockRequester(t)\n m.EXPECT().Get(mock.Anything).RunAndReturn(func(path string) (string, error) {\n return path + \" world\", nil\n })\n retString, err := m.Get(\"hello\")\n assert.NoError(t, err)\n assert.Equal(t, retString, \"hello world\")\n}\nBecause the mock embeds the testify Mock object, you can all any methods on that as well.
func TestRequesterMockTestifyEmbed(t *testing.T) {\n m := NewMockRequester(t)\n m.EXPECT().Get(mock.Anything).Return(\"\", nil).Twice()\n m.Get(\"hello\")\n m.Get(\"world\")\n assert.Equal(t, len(m.Mock.Calls), 2)\n}\ntemplate-data","text":"key type description 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 \"\" Set the build tags of the generated mocks. Read more about the format. unroll-variadic bool If set to unroll-variadic: true, will expand the variadic argument to testify using the ... syntax. See notes for more details."},{"location":"template/testify/#features","title":"Features","text":""},{"location":"template/testify/#mock-constructors","title":"Mock Constructors","text":"v2.11.0
All mock objects have constructor functions. These constructors do basic test setup so that the expectations you set in the code are asserted before the test exits.
Previously something like this would need to be done: Go
factory := &mocks.Factory{}\nfactory.Test(t) // so that mock does not panic when a method is unexpected\ndefer factory.AssertExpectations(t)\nInstead, you may simply use the constructor: Go
factory := mocks.NewFactory(t)\nThe constructor sets up common functionalities automatically
AssertExpectations method is registered to be called at the end of the tests via t.Cleanup() method.mock.Mock so that tests don't panic when a call on the mock is unexpected. v2.10.0 \u00b7 with-expecter: True
Mockery now supports an \"expecter\" struct, which allows your tests to use type-safe methods to generate call expectations. When enabled through the with-expecter: True mockery configuration, you can enter into the expecter interface by simply calling .EXPECT() on your mock object.
For example, given an interface such as Go
type Requester interface {\n Get(path string) (string, error)\n}\nYou can use the expecter interface as such: Go
requesterMock := mocks.NewRequester(t)\nrequesterMock.EXPECT().Get(\"some path\").Return(\"result\", nil)\nA RunAndReturn method is also available on the expecter struct that allows you to dynamically set a return value based on the input to the mock's call.
requesterMock.EXPECT().\n Get(mock.Anything).\n RunAndReturn(func(path string) (string, error) {\n fmt.Println(path, \"was called\")\n return (\"result for \" + path), nil\n })\nNote
Note that the types of the arguments on the EXPECT methods are interface{}, not the actual type of your interface. The reason for this is that you may want to pass mock.Any as an argument, which means that the argument you pass may be an arbitrary type. The types are still provided in the expecter method docstrings.
v2.20.0
Return Value Providers can be used one of two ways. You may either define a single function with the exact same signature (number and type of input and return parameters) and pass that as a single value to Return, or you may pass multiple values to Return (one for each return parameter of the mocked function.) If you are using the second form, for each of the return values of the mocked function, Return needs a function which takes the same arguments as the mocked function, and returns one of the return values. For example, if the return argument signature of passthrough in the above example was instead (string, error) in the interface, Return would also need a second function argument to define the error value:
type Proxy interface {\n passthrough(ctx context.Context, s string) (string, error)\n}\nFirst form:
GoproxyMock := mocks.NewProxy(t)\nproxyMock.On(\"passthrough\", mock.AnythingOfType(\"context.Context\"), mock.AnythingOfType(\"string\")).\nReturn(\n func(ctx context.Context, s string) (string, error) {\n return s, nil\n }\n)\nSecond form:
GoproxyMock := mocks.NewProxy(t)\nproxyMock.On(\"passthrough\", mock.AnythingOfType(\"context.Context\"), mock.AnythingOfType(\"string\")).\nReturn(\n func(ctx context.Context, s string) string {\n return s\n },\n func(ctx context.Context, s string) error {\n return nil\n },\n)\nConsider if we have a function func Bar(message ...string) error. A typical assertion might look like this:
func TestFoo(t *testing.T) {\n m := NewMockFoo(t)\n m.On(\"Bar\", \"hello\", \"world\").Return(nil)\nWe might also want to make an assertion that says \"any number of variadic arguments\":
Gom.On(\"Bar\", mock.Anything).Return(nil)\nHowever, what we've given to mockery is ambiguous because it is impossible to distinguish between these two intentions:
This is fixed in #359 where you can provide unroll-variadic: False to get back to the old behavior. Thus, if you want to assert (1), you can then do:
m.On(\"Bar\", mock.Anything).Return(nil)\nIf you want to assert (2), you must set unroll-variadic: True. Then this assertion's intention will be modified to mean the second case:
m.On(\"Bar\", mock.Anything).Return(nil)\nAn upstream patch to testify is currently underway to allow passing mock.Anything directly to the variadic slice: https://github.com/stretchr/testify/pull/1348
If this is merged, it would become possible to describe the above two cases respectively:
Go// case 1\nm.On(\"Bar\", mock.Anything).Return(nil)\n// case 2\nm.On(\"Bar\", []interface{}{mock.Anything}).Return(nil)\nReferences:
There might be instances where you want a mock to return different values on successive calls that provide the same arguments. For example, we might want to test this behavior:
Go// Return \"foo\" on the first call\ngetter := NewGetter()\nassert(t, \"foo\", getter.Get(\"key\"))\n\n// Return \"bar\" on the second call\nassert(t, \"bar\", getter.Get(\"key\"))\nThis can be done by using the .Once() method on the mock call expectation:
mockGetter := NewMockGetter(t)\nmockGetter.EXPECT().Get(mock.anything).Return(\"foo\").Once()\nmockGetter.EXPECT().Get(mock.anything).Return(\"bar\").Once()\nOr you can identify an arbitrary number of times each value should be returned:
GomockGetter := NewMockGetter(t)\nmockGetter.EXPECT().Get(mock.anything).Return(\"foo\").Times(4)\nmockGetter.EXPECT().Get(mock.anything).Return(\"bar\").Times(2)\nNote that with proper Go support in your IDE, all the available methods are self-documented in autocompletion help contexts.
"}]} \ No newline at end of file diff --git a/v3.0/template/index.html b/v3.0/template/index.html index 97375f88..b0908fc6 100644 --- a/v3.0/template/index.html +++ b/v3.0/template/index.html @@ -982,7 +982,7 @@template: "testify"¶testify templates generate powerful, testify-based mock objects. They allow you to create expectations using argument-to-return-value matching logic.
testify templates generate powerful, testify-based mock objects. They allow you to create expectations using argument-to-return-value matching logic.
template: "matryer"¶matryer templates draw from the mocks generated from the project at https://github.com/matryer/moq. This project was folded into mockery, and thus moq-style mocks can be natively generated from within mockery.
matryer templates draw from the mocks generated from the project at https://github.com/matryer/moq. This project was folded into mockery, and thus moq-style mocks can be natively generated from within mockery.
Mocks generated using this template allow you to define precise functions to be run. Example:
func TestRequesterMoq(t *testing.T) {
m := &MoqRequester{
diff --git a/v3.0/template/testify/index.html b/v3.0/template/testify/index.html
index e368d03c..a66e09df 100644
--- a/v3.0/template/testify/index.html
+++ b/v3.0/template/testify/index.html
@@ -654,11 +654,11 @@
-
-
+
- Replace Types
+ Mock Constructors
@@ -667,11 +667,11 @@
-
-
+
- Mock Constructors
+ Expecter Structs
@@ -680,11 +680,43 @@
-
-
+
- Expecter Structs
+ Return Value Providers
+
+
+
+
+
+
+
+
+
+
+
+
+ -
+
+
+
+
+ Notes
+
+
+
+
+
+
+
+
+
+ -
+
+
+
+
+ Notes
+
+
+
+
+
+
-If set to unroll-variadic: true, will expand the variadic argument to testify using the ... syntax. See notes for more details.
+If set to unroll-variadic: true, will expand the variadic argument to testify using the ... syntax. See notes for more details.
v2.23.0
-The replace-type parameter allows adding a list of type replacements to be made in package and/or type names.
-This can help overcome issues like usage of type aliases that point to internal packages.
The format of the parameter is:
-originalPackagePath.originalTypeName=newPackageName:newPackagePath.newTypeName
For example:
-mockery --replace-type github.com/vektra/mockery/v3/baz/internal/foo.InternalBaz=baz:github.com/vektra/mockery/v3/baz.Baz
-This will replace any imported named "github.com/vektra/mockery/v3/baz/internal/foo"
-with baz "github.com/vektra/mockery/v3/baz". The alias is defined with : before
-the package name. Also, the InternalBaz type that comes from this package will be renamed to baz.Baz.
This next example fixes a common problem of type aliases that point to an internal package.
-cloud.google.com/go/pubsub.Message is a type alias defined like this:
The Go parser that mockery uses doesn't provide a way to detect this alias and sends the application the package and -type name of the type in the internal package, which will not work.
-We can use replace-type with only the package part to replace any import of cloud.google.com/go/internal/pubsub to
-cloud.google.com/go/pubsub. We don't need to change the alias or type name in this case, because they are pubsub
-and Message in both cases.
Original source:
-import (
- "cloud.google.com/go/pubsub"
-)
-
-type Handler struct {
- HandleMessage(m pubsub.Message) error
-}
-Invalid mock generated without this parameter (points to an internal folder):
import (
- mock "github.com/stretchr/testify/mock"
-
- pubsub "cloud.google.com/go/internal/pubsub"
-)
-
-func (_m *Handler) HandleMessage(m pubsub.Message) error {
- // ...
- return nil
-}
-Correct mock generated with this parameter.
-import (
- mock "github.com/stretchr/testify/mock"
-
- pubsub "cloud.google.com/go/pubsub"
-)
-
-func (_m *Handler) HandleMessage(m pubsub.Message) error {
- // ...
- return nil
-}
-Generic type constraints can also be replaced by targeting the changed parameter with the square bracket notation on the left-hand side.
-mockery --replace-type github.com/vektra/mockery/v3/baz/internal/foo.InternalBaz[T]=github.com/vektra/mockery/v3/baz.Baz
-For example:
-type InternalBaz[T any] struct{}
-
-func (*InternalBaz[T]) Foo() T {}
-
-// Becomes
-type InternalBaz[T baz.Baz] struct{}
-
-func (*InternalBaz[T]) Foo() T {}
-If a type constraint needs to be removed and replaced with a type, target the constraint with square brackets and include a '-' in front to have it removed.
-mockery --replace-type github.com/vektra/mockery/v3/baz/internal/foo.InternalBaz[-T]=github.com/vektra/mockery/v3/baz.Baz
-For example:
-type InternalBaz[T any] struct{}
-
-func (*InternalBaz[T]) Foo() T {}
-
-// Becomes
-type InternalBaz struct{}
-
-func (*InternalBaz) Foo() baz.Baz {}
-When replacing a generic constraint, you can replace the type with a pointer by adding a '*' before the output type name.
-mockery --replace-type github.com/vektra/mockery/v3/baz/internal/foo.InternalBaz[-T]=github.com/vektra/mockery/v3/baz.*Baz
-For example:
-type InternalBaz[T any] struct{}
-
-func (*InternalBaz[T]) Foo() T {}
-
-// Becomes
-type InternalBaz struct{}
-
-func (*InternalBaz) Foo() *baz.Baz {}
-v2.11.0
All mock objects have constructor functions. These constructors do basic test setup so that the expectations you set in the code are asserted before the test exits.
Previously something like this would need to be done: -
factory := &mocks.Factory{}
-factory.Test(t) // so that mock does not panic when a method is unexpected
-defer factory.AssertExpectations(t)
+Gofactory := &mocks.Factory{}
+factory.Test(t) // so that mock does not panic when a method is unexpected
+defer factory.AssertExpectations(t)
Instead, you may simply use the constructor:
-
Gofactory := mocks.NewFactory(t)
+
The constructor sets up common functionalities automatically
@@ -1422,21 +1387,21 @@ Expecter Structs v2.10.0 ยท with-expecter: True
Mockery now supports an "expecter" struct, which allows your tests to use type-safe methods to generate call expectations. When enabled through the with-expecter: True mockery configuration, you can enter into the expecter interface by simply calling .EXPECT() on your mock object.
For example, given an interface such as
-
Gotype Requester interface {
- Get(path string) (string, error)
-}
+
You can use the expecter interface as such:
-
GorequesterMock := mocks.NewRequester(t)
-requesterMock.EXPECT().Get("some path").Return("result", nil)
+GorequesterMock := mocks.NewRequester(t)
+requesterMock.EXPECT().Get("some path").Return("result", nil)
A RunAndReturn method is also available on the expecter struct that allows you to dynamically set a return value based on the input to the mock's call.
-GorequesterMock.EXPECT().
- Get(mock.Anything).
- RunAndReturn(func(path string) (string, error) {
- fmt.Println(path, "was called")
- return ("result for " + path), nil
- })
+GorequesterMock.EXPECT().
+ Get(mock.Anything).
+ RunAndReturn(func(path string) (string, error) {
+ fmt.Println(path, "was called")
+ return ("result for " + path), nil
+ })
Note
@@ -1445,31 +1410,86 @@ Expecter StructsReturn Value Providers¶
v2.20.0
Return Value Providers can be used one of two ways. You may either define a single function with the exact same signature (number and type of input and return parameters) and pass that as a single value to Return, or you may pass multiple values to Return (one for each return parameter of the mocked function.) If you are using the second form, for each of the return values of the mocked function, Return needs a function which takes the same arguments as the mocked function, and returns one of the return values. For example, if the return argument signature of passthrough in the above example was instead (string, error) in the interface, Return would also need a second function argument to define the error value:
-Gotype Proxy interface {
- passthrough(ctx context.Context, s string) (string, error)
-}
+
First form:
-GoproxyMock := mocks.NewProxy(t)
-proxyMock.On("passthrough", mock.AnythingOfType("context.Context"), mock.AnythingOfType("string")).
-Return(
- func(ctx context.Context, s string) (string, error) {
- return s, nil
- }
-)
+GoproxyMock := mocks.NewProxy(t)
+proxyMock.On("passthrough", mock.AnythingOfType("context.Context"), mock.AnythingOfType("string")).
+Return(
+ func(ctx context.Context, s string) (string, error) {
+ return s, nil
+ }
+)
Second form:
-GoproxyMock := mocks.NewProxy(t)
-proxyMock.On("passthrough", mock.AnythingOfType("context.Context"), mock.AnythingOfType("string")).
-Return(
- func(ctx context.Context, s string) string {
- return s
- },
- func(ctx context.Context, s string) error {
- return nil
- },
-)
+GoproxyMock := mocks.NewProxy(t)
+proxyMock.On("passthrough", mock.AnythingOfType("context.Context"), mock.AnythingOfType("string")).
+Return(
+ func(ctx context.Context, s string) string {
+ return s
+ },
+ func(ctx context.Context, s string) error {
+ return nil
+ },
+)
+
+Notes¶
+Variadic Arguments¶
+Consider if we have a function func Bar(message ...string) error. A typical assertion might look like this:
+
+We might also want to make an assertion that says "any number of variadic arguments":
+
+However, what we've given to mockery is ambiguous because it is impossible to distinguish between these two intentions:
+
+- Any number of variadic arguments of any value
+- A single variadic argument of any value
+
+This is fixed in #359 where you can provide unroll-variadic: False to get back to the old behavior. Thus, if you want to assert (1), you can then do:
+
+If you want to assert (2), you must set unroll-variadic: True. Then this assertion's intention will be modified to mean the second case:
+
+An upstream patch to testify is currently underway to allow passing mock.Anything directly to the variadic slice: https://github.com/stretchr/testify/pull/1348
+If this is merged, it would become possible to describe the above two cases respectively:
+Go// case 1
+m.On("Bar", mock.Anything).Return(nil)
+// case 2
+m.On("Bar", []interface{}{mock.Anything}).Return(nil)
+
+References:
+
+- https://github.com/vektra/mockery/pull/359
+- https://github.com/vektra/mockery/pull/123
+- https://github.com/vektra/mockery/pull/550
+- https://github.com/vektra/mockery/issues/541
+
+Multiple Expectations With Identical Arguments¶
+There might be instances where you want a mock to return different values on successive calls that provide the same arguments. For example, we might want to test this behavior:
+Go// Return "foo" on the first call
+getter := NewGetter()
+assert(t, "foo", getter.Get("key"))
+
+// Return "bar" on the second call
+assert(t, "bar", getter.Get("key"))
+
+This can be done by using the .Once() method on the mock call expectation:
+GomockGetter := NewMockGetter(t)
+mockGetter.EXPECT().Get(mock.anything).Return("foo").Once()
+mockGetter.EXPECT().Get(mock.anything).Return("bar").Once()
+
+Or you can identify an arbitrary number of times each value should be returned:
+GomockGetter := NewMockGetter(t)
+mockGetter.EXPECT().Get(mock.anything).Return("foo").Times(4)
+mockGetter.EXPECT().Get(mock.anything).Return("bar").Times(2)
+Note that with proper Go support in your IDE, all the available methods are self-documented in autocompletion help contexts.
diff --git a/v3.0/v3/index.html b/v3.0/v3/index.html
index 5d946eae..d231d894 100644
--- a/v3.0/v3/index.html
+++ b/v3.0/v3/index.html
@@ -844,16 +844,197 @@
-
-
+
- v2 Migration
+ Migration
+
+
+
+
+
+
+
@@ -899,16 +1080,197 @@
-
-
+
- v2 Migration
+ Migration
+
+
+
+
+
+
+
@@ -947,16 +1309,47 @@
v3 Release¶
Mockery releases version 3 of the project that provides a number of high-profile benefits over v2:
-- Allows generation of
matryer-style templates. The https://github.com/matryer/moq project is being folded into mockery to combine the speed and configuration flexibility of mockery with the simplicity of moq-style mocks.
+- Allows generation of
matryer-style templates. The https://github.com/matryer/moq project is being subsumed into mockery to combine the speed and configuration flexibility of mockery with the simplicity of moq-style mocks.
- Changes the generation scheme to be entirely driven off of Go templates. This means that the data provided to templates is considered as part of the public API.
- Mockery now allows users to specify their own templates to make code generation far easier. Mockery handles the problem of parsing source code and enables you to focus on creating your own interface implementations.
- Shedding all deprecated variables and simplifying the way in which mocks are configured.
-v2 Migration¶
-
-Construction
-This section is under construction.
-
+Migration¶
+Mockery-style mocks¶
+In v3, mockery is capable of producing two styles of mocks. In v3, the mockery-style mocks are called testify and can be used by setting template: testify. The shape of the mocks should be identical (minus the now-required expecter methods) and should not require any changes to existing tests using testify-style mocks.(1)
+
+- If this is not the case and the v3
testify-style mocks have breaking changes, please submit an issue on Github.
+
+Deprecation Warnings¶
+Mockery v2 has explicitly deprecated a number of variables. These deprecations can be found here: https://vektra.github.io/mockery/latest-v2/deprecations/. Mockery logs warnings such as:
+20 Jan 25 15:53 CST WRN DEPRECATION: disable-version-string will be permanently set to True in v3 deprecation-name=disable-version-string url=https://vektra.github.io/mockery/v0.0/deprecations/#disable-version-string version=v0.0.0-dev
+20 Jan 25 15:53 CST WRN DEPRECATION: issue-845-fix must be set to True to remove this warning. Visit the link for more details. deprecation-name=issue-845-fix url=https://vektra.github.io/mockery/v0.0/deprecations/#issue-845-fix version=v0.0.0-dev
+20 Jan 25 15:53 CST WRN DEPRECATION: resolve-type-alias will be permanently set to False in v3. Please modify your config to set the parameter to False. deprecation-name=resolve-type-alias url=https://vektra.github.io/mockery/v0.0/deprecations/#resolve-type-alias version=v0.0.0-dev
+20 Jan 25 15:53 CST WRN DEPRECATION: with-expecter will be permanently set to True in v3 deprecation-name=with-expecter url=https://vektra.github.io/mockery/v0.0/deprecations/#with-expecter version=v0.0.0-dev
+
+These warnings provide doc URLs that indicate how to fix the warning to prepare for the v3 release. While we provide these warnings on a best-effort basis, they are unlikely to be comprehensive due to the large number of changes that v3 introduces. Please submit an issue on Github if you notice a missing deprecation warning that would be useful to have.
+Layouts¶
+In v2, mockery defaulted to placing mocks in a separate mocks/ directory as shown here. In v3, mockery will by default place mocks adjacent to the mocked interface.
+It is still possible to place mocks in a separate directory by making use of the template variables and functions available to the configuration parameters.
+Function Mocks¶
+Mockery v2 allowed generating mocks for function types. v3 no longer does this as it provided little benefit for users.
+Parameters¶
+inpackage: True¶
+Mockery v2 has an inpackage parameter that informed mockery when a mock was being generated in the same package as the original interface. In v3, this parameter has been removed as mockery is now able to detect when the mock is placed in the same package.
+keeptree: True¶
+Mockery v2 provided a keeptree parameter that was deprecated and used only in the pre-packages config schema. This parameter has no use in v3 and has been removed.
+replace-type:¶
+The replace-type: parameter has an updated schema. In v2, users provided a list of strings, where each string needed to confirm to a specific format that was parsed at runtime. In v3, the schema is more explicit to make it simpler.
+struct-name:¶
+The struct-name parameter has been replaced with mock-name.
+resolve-alias:¶
+In v2, resolve-alias was set to True by default to retain backwards compatability. In v3, this is set to False by default.
+with-expecter:¶
+In v3, this parameter has been removed. testify-style mocks will always generate expecter methods.
+unroll-variadic:¶
+This parameter has been moved under the template-data: parameter. Parameters that apply only to specific templates are not expressed in the top-level schema and are instead passed through the schemaless template-data: map.
+exclude:¶
+This parameter in v2 was renamed to exclude-subpkg-regex:.
diff --git a/versions.json b/versions.json
index 3f59418d..0c07cbbc 100644
--- a/versions.json
+++ b/versions.json
@@ -10,8 +10,8 @@
"version": "v2.51",
"title": "v2.51",
"aliases": [
- "latest",
- "latest-v2"
+ "latest-v2",
+ "latest"
]
},
{