I wouldn't describe swapping a persisted DB for an in-memory DB mocking personally.
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")
}
func TestContrivedFunction(t *testing.T) {
db := mocks.NewDB(t)
if ContrivedFunction(db) != "value" {
t.Error("unexpected result")
}
}
But, okay. It is still something. We will play its game:
func TestContrivedFunction(t *testing.T) {
db := mocks.NewDB(t)
db.Mock.On("Set", "key", "value").Return()
db.Mock.On("Get", "key").Return("value")
if ContrivedFunction(db) != "value" {
t.Error("unexpected result")
}
}
But now, the contrived project manager just called and, for contrived reasons, would like to change the organization of record keys:
func ContrivedFunction(db DB) string {
db.Set("ns:key", "value")
return db.Get("ns:key")
}
But not only is it broken, it doesn't seem to serve a purpose. Why would you even use it?
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.
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.
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.
What have you got?