Configuration¶

`mockery init`¶

mockery init [module_name] is a useful command that can bootstrap you with a fully-functioning configuration set. For example, if we run:

$ mockery init github.com/vektra/mockery/v3/internal/fixtures
2025-03-14T23:06:12.535709000-05:00 INF writing to file file=.mockery.yml version=v0.0.0-dev
2025-03-14T23:06:12.536493000-05:00 INF done version=v0.0.0-dev

.mockery.yml

all: false
dir: '{{.InterfaceDir}}'
filename: mocks_test.go
force-file-write: false
formatter: goimports
log-level: info
structname: {{.Mock}}{{.InterfaceName}}
pkgname: '{{.SrcPackageName}}'
recursive: false
template: testify
packages:
  github.com/vektra/mockery/v3/internal/fixtures:
    config:
      all: true

We can then run mockery against this config to generate the code:

$ mockery
2025-03-14T23:42:17.014113000-05:00 INF Starting mockery config-file=/Users/landon/git/LandonTClipp/mockery/.mockery.yaml version=v0.0.0-dev
2025-03-14T23:42:17.014258000-05:00 INF Parsing configured packages... version=v0.0.0-dev
2025-03-14T23:42:17.527483000-05:00 INF Done parsing configured packages. version=v0.0.0-dev
[...]
2025-03-14T23:42:17.531239000-05:00 INF Executing template file=/Users/landon/git/LandonTClipp/mockery/internal/fixtures/mocks_test.go version=v0.0.0-dev
2025-03-14T23:42:17.690601000-05:00 INF Writing template to file file=/Users/landon/git/LandonTClipp/mockery/internal/fixtures/mocks_test.go version=v0.0.0-dev

$ head -n 17 /Users/landon/git/LandonTClipp/mockery/internal/fixtures/mocks_test.go
// Code generated by mockery; DO NOT EDIT.
// github.com/vektra/mockery

package test

import (
        "encoding/json"
        "io"
        "net/http"
        "unsafe"

        mock "github.com/stretchr/testify/mock"
        http1 "github.com/vektra/mockery/v3/internal/fixtures/12345678/http"
        "github.com/vektra/mockery/v3/internal/fixtures/constraints"
        http0 "github.com/vektra/mockery/v3/internal/fixtures/http"
        test "github.com/vektra/mockery/v3/internal/fixtures/redefined_type_b"
)

Extended Example

A more complex configuration example can be seen below:

YAML

all: False
template-data:
  boilerplate-file: ./path/to/boilerplate.txt
template: testify
packages:
  github.com/vektra/example:
    config:
      # Make use of the template variables to place the mock in the same
      # directory as the original interface.
      dir: "{{.InterfaceDir}}"
      filename: "mocks_test.go"
      outpkg: "{{.PackageName}}_test"
      structname: "{{.Mock}}{{.InterfaceName}}"
    interfaces:
      Foo:
      Bar:
        config:
          # Make it unexported instead
          structname: "mock{{.InterfaceName}}"
      Baz:
        # Create two mock implementations of Baz with different names.
        configs:
          - filename: "mocks_baz_one_test.go"
            structname: "MockBazOne"
          - filename: "mocks_baz_two_test.go"
            structname: "MockBazTwo"
  io:
    config:
      dir: path/to/io/mocks
      filename: "mocks_io.go"

These are the highlights of the config scheme:

The parameters are merged hierarchically
There are a number of template variables available to generalize config values.
The style of mock to be generated is specified using the template parameter.

Parameter Descriptions¶

name	default	description
`all`	`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`	`"{{.InterfaceDir}}"`	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-interface-regex`	`""`	When set along with `include-interface-regex`, then interfaces which match `include-interface-regex` but also match `exclude-interface-regex` will not be generated. If `all` is set, or if `include-interface-regex` is not set, then `exclude-interface-regex` has no effect.
`filename`	`"mocks_test.go"`	The name of the file the mock will reside in.
`force-file-write`	`true`	When set to `force-file-write: true`, mockery will forcibly overwrite any existing files. Otherwise, it will fail if the output file already exists.
`formatter`	`"goimports"`	The formatter to use on the rendered template. Choices are: `gofmt`, `goimports`, `noop`.
`include-interface-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-interface-regex`.
`log-level`	`"info"`	Set the level of the logger
`structname`	`"{{.Mock}}{{.InterfaceName}}"`	The name of the generated interface implementation.
`packages`	`null`	A dictionary containing configuration describing the packages and interfaces to generate mocks for.
`pkgname`	`"{{.SrcPackageName}}"`	The `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.
`build-tags`	`""`	A space-separated list of additional build tags to load packages.
`require-template-schema-exists`	`true`	If set to `true` and the schema failed to download, mockery will fail. Otherwise, mockery will not attempt to download the file nor do any schema validation.
`template`	`""`	The template to use. The choices are defined in the Templates section.
`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.
`template-schema`	`"{{.Template}}.schema.json"`	The URL of the JSON schema to apply to the `template-data` parameter. See the template docs for more details.

Templates¶

Parameters marked as being templated have access to a number of template variables and functions through the Go text/template system.

Variables¶

The variables provided are specified in the config.Data struct.

Functions¶

All of the functions defined in StringManipulationFuncs are available to templated parameters.

Config sources¶

Config can not only be specified from the .yml file, but also from CLI parameters (where available) and environment variables. For example, specifying a boolean value for a particular parameter called enable-feature from each config source would look like this:

source	value
command line	`--enable-feature=true`
Environment variable	`MOCKERY_ENABLE_FEATURE=True`
yaml	`enable-feature: True`

Config is loaded from each source in the following order:

Default values
Environment variables
Config file
CLI Parameters