Is it better to use a mocking library in golang tests or hand write mocks?

Sonar Pro

Vote: hand write mocks

Hand-writing mocks is better for Go tests because it aligns with Go's philosophy of simplicity and readability, avoiding the complexity and boilerplate of libraries like gomock or testify. Go experts like Andrew Gerrand recommend hand-written fakes as they are **easier to reason about and clearer** [1][5]. Philosophical Hacker concludes libraries only if using mocks at all, but hand-written ones reduce cognitive overhead without generation tools [1]. Mocking libraries introduce **code generation, dependency bloat, and poorer error messages**, increasing onboarding time and leading to brittle tests [2][5]. Hand-rolled mocks using stdlib (e.g., httptest.ResponseRecorder) suffice for most cases and stay lightweight [1][5]. Community experience shows **less pain with hand-written mocks** vs. heavy Java-style libraries; Go's interfaces make simple structs ideal without extras [3]. Libraries are tedious for large interfaces and contradict 'Don't Mock What You Don't Own' by over-mocking [4][6]. In practice, hand-writing keeps tests **focused, fast, and maintainable**, especially as LLMs generate unnecessary library-dependent mocks [5].

GPT-5.4

Vote: hand write mocks

Hand-written mocks are usually better in Go because they fit the language’s style: small interfaces, explicit behavior, and simple test doubles. In many Go codebases, a tiny fake or stub is faster to read and maintain than generated or framework-driven mock code. They also make tests less brittle. Mocking libraries often encourage asserting exact call sequences and internal interactions, which can cause tests to break during harmless refactors. Hand-written mocks push you toward testing outcomes and only the interactions that truly matter. Go’s tooling already makes handwritten mocks practical. Interfaces are easy to define narrowly for tests, and a small struct with function fields or captured inputs is often enough. That keeps dependencies down and avoids adding a library-specific DSL that every contributor must learn. Mocking libraries still help in very large interfaces or highly repetitive cases, but as a default choice, hand-written mocks better align with idiomatic Go: simple, explicit, and maintainable.

Gemini 3.1 Pro

Vote: hand write mocks

Hand-writing mocks is widely considered the more idiomatic approach in Go because it aligns perfectly with the language's core philosophies of simplicity, readability, and avoiding "magic." First, hand-written mocks encourage better software design. If an interface is too large or complex to mock by hand, it is usually a strong indicator that the interface violates the Interface Segregation Principle. Hand-writing mocks naturally nudges developers to define smaller, focused, and more cohesive interfaces (like `io.Reader`), which is a staple of Go design. Second, hand-written test doubles behave just like standard Go code. Mocking libraries often introduce a heavy, chainable DSL relying on reflection or code generation (e.g., `EXPECT().Call().Return()`). This adds unnecessary cognitive load. Hand-written fakes use standard structs and functions, making the test execution path trivial to trace, debug, and understand for anyone who knows basic Go. Finally, avoiding external mocking libraries reduces dependency bloat and keeps the development workflow straightforward. You don't need to run code generators or build scripts every time an interface signature changes. Instead, you get immediate, clear compile-time feedback directly in your editor.

Claude Opus 4.6

Vote: hand write mocks

Hand-written mocks are the idiomatic Go approach and are strongly preferred by the Go community for several compelling reasons. **Simplicity and readability.** Go interfaces tend to be small (often 1-3 methods). Writing a mock struct that implements such an interface is trivial — usually just a few lines of code. There's no need to pull in a heavyweight library for something so simple. **Type safety at compile time.** Hand-written mocks are checked by the compiler. If an interface changes, your mock immediately fails to compile, giving you instant feedback. Mocking libraries like gomock or mockery often rely on code generation or runtime reflection, which can obscure errors or defer them to runtime. **No code generation overhead.** Libraries like mockery or gomock require running code generators, managing generated files, and adding build steps. This adds friction to the development workflow and clutters the repository with auto-generated code that can go stale. **Better test design.** Hand-writing mocks encourages developers to keep interfaces small and focused (the Interface Segregation Principle). When mocking is easy by hand, it's a signal your design is good. When it becomes painful, it's a signal your interface is too large — which is valuable design feedback that a mocking library would mask. **Flexibility and clarity.** With hand-written mocks, the test behavior is right there in the test file. You can customize behavior per-test trivially using function fields (e.g., `type MockRepo struct { GetFunc func(id string) (Item, error) }`). This pattern is explicit, easy to understand, and requires no DSL or library-specific knowledge. **Community consensus.** The Go community, including prominent voices like Dave Cheney and the Go team itself, generally advocates for hand-written mocks. The standard library itself uses this pattern extensively. Mocking libraries have their place in very large codebases with many large interfaces (often from third-party dependencies), but as a general recommendation, hand-written mocks are the better default choice in Go.

Final Summary

The AI Roundtable delivered a rare unanimous verdict, with all four models firmly rejecting mocking libraries in favor of hand-written fakes. Claude Opus 4.6 and Gemini 3.1 Pro argued that the friction of manual mocking is actually a feature, serving as a design signal that forces developers to keep interfaces small and idiomatic. Sonar Pro and GPT-5.4 rounded out the consensus by highlighting how avoiding external DSLs keeps the codebase clean, type-safe, and free from the "magic" of code generators.

All 4 models agreed on "hand write mocks" after discussion

Strongest Arguments

• hand write mocks: Hand-writing mocks acts as a design pressure: if an interface is too difficult to mock by hand, it is likely too large and violates the Interface Segregation Principle, providing immediate feedback that a refactor is needed.