ASashconnor·Apr 11, 2024
I'm far too lazy to write mocks by hand in go. You can generate a mock for a given interface with mockery https://github.com/vektra/mockery
In How I write unit tests in Govektra
mockery
Go2017–2024
vektra / mockery
mockery
A mock code autogenerator for Go
5Distinct people
5Mentions
0Explicit recommenders
7.2KGitHub stars
What to know before exploring
What it is
A mock code autogenerator for Go
GitHub
Where it is used
No documented product use has been verified yet.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
No other repository is repeatedly linked in the same discussions.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:56:07 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year5 dated mentions
Observed mentions: 2017-12-11 07:33:31 UTC to 2024-04-11 04:33:43 UTC.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 2 | 1 | 1 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 1 | 0 | 1 |
What Hacker News says
5 sourcesI've found that unless I write code in golang in a way that was intentionally written to be unit tested, it is very hard to bolt on unit testing after the fact. I'm stuck with effectively just integration testing. I don't envy you working on legacy code.
struct Foo {
}
func (f *Foo) doSomething() {
client := pkg.NewClient()
client.doHttpRequest()
}
vs.
struct Foo {
client Client
}
func (f *Foo) doSomething() {
f.client.doHttpRequest()
}
func NewFoo(client Client) *Foo {
return &Foo{ client: client }
}
var FooModule = fx.Provide(NewFoo)
then to use it...
struct Bar {
foo *Foo
}
func NewBar(foo *Foo) *Bar {
return &Bar{foo: foo}
}
var BarModule = fx.Provide(NewBar)
how do you unit test the first example? There is no easy way to that without having the client do things s
Read the rest
pecial internally, which leads to a rats nest of issues and doesn't scale. Easier to just pass in a mock client and make sure the right http request/responses are being done.
fx kind of highly encourages the second approach for all of your code. It is a bit more boilerplate, but by default, I'm always going to be thinking about passing my dependencies around instead of just being lazy and doing NewClient in the function.
I also get to take advantage of the fact that Client is just magically passed into my constructor. If there is some error doing so (like I forget to Provide), then fx will give me errors at start up. My dependency chain is clear. It just feels nicer to me.
Once again, of course I can write it the second way without fx... but it is kind of nice that every time I want to use Foo, I don't have to type NewFoo() in a constructor... I just reference *Foo.
By the way, mockery [1] generates super easy to use mocks for exactly this workflow.
[1] https://github.com/vektra/mockery
Show HN: Simple Go mocks without interface{}s
I've been a pretty happy user of mockery [1] for a while, but recently found it getting a lot in my way.
Since mockery uses a lot of interface{} magic, adding arguments or return values to interfaces and regenerating the mocks does not get the compiler to complain about existing, now invalid, usages of the mocks. This means that I have to track them down manually. Or, if I'm brave enough, try my hand at a few crazy regexes that never get the job 100% done.
go-mocky does not use interface{}s, and thus can't hide changes to function signatures from the compiler; whenever a mock has been updated and the function signature has changed, the compiler will complain for all existing tests. This means that I can now catch errors at compile/lint time instead of runtime.
Another added benefit is that the go-mocky mocks are dead simple and very easy
Read the rest
to write and maintain by hand, should the need ever arise.
[1]: https://github.com/vektra/mockery
Please don't. I mean, do, whatever makes you happy. There's at least 3 of these flying around in various stages of abandonment.
Here's one:
https://github.com/vektra/mockery
In Ask HN: How to approach testing in Golang?Design components based on interfaces. Use dependency injection, Testify [0] for asserts and mocks, and Mockery (based on Testify) [1] to generate mocks.
[0] https://github.com/stretchr/testify
[1] https://github.com/vektra/mockery
In Ask HN: How to approach testing in Golang?