• Stars
    star
    5,859
  • Rank 6,921 (Top 0.2 %)
  • Language
    Go
  • License
    BSD 3-Clause "New...
  • Created about 10 years ago
  • Updated 4 months ago

Reviews

There are no reviews yet. Be the first to send feedback to the community and the maintainers!

Repository Details

A mock code autogenerator for Go

mockery

Release go.dev reference GitHub go.mod Go version GitHub release (latest SemVer) Go Report Card codecov

mockery provides the ability to easily generate mocks for Golang interfaces using the stretchr/testify/mock package. It removes the boilerplate coding required to use mocks.

Documentation

Documentation is found at out GitHub Pages site.

Development

taskfile.dev is used for build tasks. Initialize all go build tools:

go mod download -x

You can run any of the steps listed in Taskfile.yml:

$ task test
task: [test] go test -v -coverprofile=coverage.txt ./...

Development Efforts

v1

v1 is the original version of the software, and is no longer supported.

v2

mockery is currently in v2, which originally included cosmetic and configuration improvements over v1, but also implements a number of quality-of-life additions.

v3

v3 will include a ground-up overhaul of the entire codebase and will completely change how mockery works internally and externally. The highlights of the project are:

  • Moving towards a package-based model instead of a file-based model. mockery currently iterates over every file in a project and calls package.Load on each one, which is time-consuming. Moving towards a model where the entire package is loaded at once will dramatically reduce runtime, and will simplify logic. Additionally, supporting only a single mode of operation (package mode) will greatly increase the intuitiveness of the software.
  • Configuration-driven generation. v3 will be entirely driven by configuration, meaning:
    • You specify the packages you want mocked, instead of relying on it auto-discovering your package. Auto-discovery in theory sounds great, but in practice it leads to a great amount of complexity for very little benefit.
    • Package- or interface-specific overrides can be given that change mock generation settings on a granular level. This will allow your mocks to be generated in a heterogeneous manner, and will be made explicit by YAML configuration.
  • Proper error reporting. Errors across the board will be done in accordance with modern Golang practices
  • Variables in generated mocks will be given meaningful names.

Stargazers

Stargazers over time