For table-based testing, I have been using map[string]struct{...} for a while now instead of including the test name as a struct field. I have found it improves readability slightly and makes it harder to misname test cases (empty strings stand out more and duplicates won't compile).
Also, the shadowing of t in t.Run is intentional. You should not try to work around it. There's no risk of confusion either because you will always use the right one in the right place.
Per the dictionary, mock is defined as "not authentic or real, but without the intention to deceive."
As that applies to software, a mock is a fully-fledged implementation of an interface, but not the implementation you use under normal use. For example, a mock might be an in-memory database where you normally use a persisted database. Not the real implementation, but does not try to deceive – it is equally functional.
Mockery appears to be an assertion library that, bizarrely, moves the assertions into interface implementation. What purpose does it serve? You are going to end up testing implementation details by using that, which is a horrible road to go down.
> Mockery is equally function in the sense that it implements the interface it targets.
Consider a function with a key/value database dependency:
type DB interface {
Get(key string) string
Set(key string, value string)
}
func ContrivedFunction(db DB) string {
db.Set("key", "value")
return db.Get("key")
}
And let's test it using mockery:
func TestContrivedFunction(t *testing.T) {
db := mocks.NewDB(t)
if ContrivedFunction(db) != "value" {
t.Error("unexpected result")
}
}
Code looks reasonable enough, but then... Epic failure. This should work, at least it should if `db` is a mock. But it does not work. `db` deceived us. Clearly not a mock in any sense of the word.
But, okay. It is still something. We will play its game:
Ah, fuck! The test just broke again. But it shouldn't have. The utility of ContrivedFunction – that which is under test – hasn't changed one bit. The DB implementation should have been able to handle this just fine. The DB implementation used in production handles this just fine. This mockery tool is fundamentally broken.
But not only is it broken, it doesn't seem to serve a purpose. Why would you even use it?
Mocks are especially useful when you want to test code heavy with dependency injection.
I like to say that normal tests where you test by passing in params and assert the result is outside in testing.
Mocking is inside out test. Follows naturally from dependency inversion of di. You want to assert your function is making the right calls/params to it's dependencies interfaces from inside.
In your contrived example there is not much value in knowing whether "ns:key" or "key" was used. But if you those are params to some external RPC suddenly this actually becomes pretty useful.
Providing working fakes for every dependency isn't always realistic.
Should I really spend time building a fake of Stripe. Or should I just assert the request I am making to it are the expected ones.
TLDR: I only saw the value of mocks when testing DI server code with many external service dependencies.
> Providing working fakes for every dependency isn't always realistic.
I don't know what a fake is. Is that what mockery gives you? Per the dictionary, fake is defined similar to mock, but without the no deception condition, so I suppose that adds up.
There are also stubs, which is defined as something that is truncated or a part of. Which, as it pertains to software, is an implementation that implements some kind of bare minimum to satisfy the interface – often returning canned responses, for example. Mockery arguably also fits here, except the assertion part, which is something else. But I guess that's where fake comes in to draw that differentiation?
> But if you those are params to some external RPC suddenly this actually becomes pretty useful.
Sure, a stub might check the inputs and return an error if some condition is not met, without needing to implement the service in full. This remains true to what the real service would also do.
But that's not what mockery does. It just blows up spectacularly if something wasn't right. That doesn't really make any sense. That is now how the real implementation works. Not only that, but in the case of mockery, its documentation advises that you put the dependency logic in the test. How silly is that? Now when you replace Stripe with Line all your tests are broken. If you used a stub, you merely change the stub to match and you're good to go. This way the tests remain pure, as they need to as they are the contract you make with your users. Changing the contract is unacceptable.
And for all that, it doesn't seem to serve any purpose. But we did ask the other guy for a concrete example (i.e. code) to show where one would want to use it. Looking forward to it.
What's the alternative? It's not always easy or practical to reach for "alternative DB implementation" because in most cases that simply doesn't exist.
Without knowing when mockery is useful, it is impossible to suggest an alternative. There may not be a viable alternative in some cases. That is why I ask. Perhaps you can give us a concrete example to work with, even if contrived? Where have you found mockery to be useful?
The above example, of course, isn't a good one as you can inject an in-memory database (i.e. a hash map) with far less effort than running the mockery tool. But, you are quite right that not all situations are as simple.
If I recall correctly, rsc says to just buckle up and provide a working implementation no matter how hard or how much work it requires, but that's easy for someone who works for Google, in a prestigious position at that, to say. We don't all live in the same lap of luxury. I grant some pragmatism here.
So unless I pepper every test and subtest with t.Parallel() it will always run sequentially ? I gotta try that. Also I wish I could just declare that once
It's perfectly ok to take what you like from them and leave the things you don't.
Is something that has 7 useful things and 3 things you disagree with merited to be buried from public view because of the 3 things you personally disagree with?
One day, I will be working with someone who will have read this article when they were learning Go, and we will disagree about these three points. I was hoping someone would add their own opinion about these, so that when it happens, I can go back to this thread and have enough information to decide whether to change my mind or not.
Also, the shadowing of t in t.Run is intentional. You should not try to work around it. There's no risk of confusion either because you will always use the right one in the right place.