mockey
Mockey is a Go mocking library from ByteDance that enables quick mocking of functions, methods, and variables at runtime without requiring interface definitions. It is actively maintained and widely adopted internally (7k+ repos), requiring disabled inlining during compilation to function.
Key facts
Objective fields from the source. Values we can't verify are shown as “Unknown” rather than guessed.
| Field | Value |
|---|---|
| Repository | bytedance/mockey |
| Owner | bytedance |
| Primary language | Go |
| License | Apache-2.0 — OSI-approved |
| Stars | 900 |
| Forks | 45 |
| Open issues | 4 |
| Latest release | v1.4.6 (2026-04-17) |
| Last updated | 2026-04-17 |
| Source | https://github.com/bytedance/mockey |
What mockey is
Mockey rewrites function instructions at runtime (similar to monkey-patching), supporting simple/generic/variadic functions, methods with value/pointer receivers, hook functions, goroutine filtering, and conditional/sequence mocking. It requires Go 1.13+, disabling compile optimizations, and works on Linux, macOS, and Windows (AMD64, ARM64).
Get the mockey source
Clone the repository and explore it locally.
git clone https://github.com/bytedance/mockey.gitcd mockey# follow the project's README for install & configurationNeed it deployed, integrated, or customized instead? DEV.co ships production installs.
Best use cases
Implementation considerations
- Build step must disable inlining and optimizations; typical flag: `go test -gcflags="-l -N"`. Failure to do so causes mocks to be silently ignored.
- Integrate with goconvey's `PatchConvey` or Mockey's `PatchRun` (v1.4.1+) to auto-cleanup mocks and avoid test pollution.
- Generic mocking requires explicit `MockGeneric` or `Mock` with opt-in for Go 1.20+; v1.3.1+ resolves gcshape interference but requires careful mock release ordering (LIFO).
- Hook functions must match the original function signature; receiver can be omitted in method hooks if not used.
- Supports goroutine filtering (inclusion/exclusion/targeting) for concurrent test scenarios; use `Mocker` interface for advanced inspection (call counts, etc.).
When to avoid it — and what to weigh
- Production Code Patching — Mockey is designed for testing only. Runtime instruction rewriting is unstable for production use and incompatible with certain deployment models (e.g., statically compiled, optimization-enabled builds).
- Zero Compilation Overhead Requirement — Requires explicit disabling of inlining and optimization at build time (non-standard compiler flags), which may conflict with performance-critical build pipelines or CI/CD constraints.
- Interface-Heavy Architecture Already in Place — If your codebase already uses dependency injection and interfaces extensively, Mockey adds little value and introduces non-standard testing patterns that may confuse new contributors.
- Strict Determinism & Reproducibility — Runtime instruction rewriting can be sensitive to CPU architecture, Go version, or compiler internals; long-term stability across major Go releases is Unknown.
License & commercial use
Apache License 2.0 (Apache-2.0). Permissive OSI-approved license allowing commercial use, modification, and distribution under stated conditions (attribution, license/copyright notice, CHANGES disclosure).
Apache-2.0 is permissive and generally allows commercial use in closed-source projects, provided you include the original license and copyright notices. However, this is a testing library; consult legal for deployment model specifics. Use is scoped to test builds, not production artifacts.
DEV.co evaluation signals
Editorial assessment — not user reviews. Directional, with an explicit confidence level.
| Signal | Assessment |
|---|---|
| Maintenance | Active |
| Documentation | Adequate |
| License clarity | Clear |
| Deployment complexity | Moderate |
| DEV.co fit | Good |
| Assessment confidence | High |
No explicit security vulnerabilities documented in DATA. Runtime instruction rewriting poses inherent risks: if mocks persist or conflict, they could mask bugs or cause unpredictable behavior. Restrict mock scope to test binaries and ensure cleanup. No security audit or advisories mentioned; verify code review practices for your risk profile.
Alternatives to consider
GoMonkey
Similar runtime patching approach; more mature than Mockey. Use if you prefer established ecosystem or have legacy GoMonkey tests.
Testify/Mock
Interface-based mocking. Use if code already uses interfaces or you prefer declarative, type-safe mocks without runtime rewriting.
Gomock (mockgen)
Code-generation approach for interface mocks. Use if you prefer compile-time safety and avoid runtime instruction rewriting overhead.
Build on mockey with DEV.co software developers
Evaluate Mockey for your Go testing workflow. We help teams integrate mocking libraries, set up CI/CD flags, and architect test suites. Contact our engineers for a technical review.
Talk to DEV.coRelated on DEV.co
Explore the category and the services that help you build with it.
mockey FAQ
Do I have to use goconvey with Mockey?
How do I disable inlining and optimizations?
Can I mock unexported functions or methods?
What Go versions are supported?
Work with a software development agency
Need help beyond evaluating mockey? DEV.co is a software development agency offering software development services and web development for teams of every size. Our software developers and web developers build custom software, web applications, APIs, and open-source testing integrations — and maintain them long-term.
Ready to Streamline Go Testing?
Evaluate Mockey for your Go testing workflow. We help teams integrate mocking libraries, set up CI/CD flags, and architect test suites. Contact our engineers for a technical review.