-
Notifications
You must be signed in to change notification settings - Fork 24
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Stricter call matching possible? #36
Comments
I can't test it right now, but I'm pretty sure testify lets you do this by providing different expecations:
Alternatively, you could use |
I don't see any difference in the example mocks you defined here except for the path in redis? I would be really interested in how you would use |
I see, I didn't understand you at first. I haven't tested these, but this should do what you want:
Or, if you prefer to have separate expections:
|
I tried to use this one of your examples:
This can't be done though, because `type *mock.Call has no field or method DoAndReturn? |
Sorry, I got my mocking frameworks mixed up. Unfortunatly, testify mock package doesn't have a way to dynamically return, but a quick search brought this up: stretchr/testify#350 which will solve your problem. |
I'm having problems with redismock catching other calls for the same operation, which shouldn't be mocked.
For instance, I have a function where I call
Scan
two times, and I only want to mock the second call to simulate an error being returned. This seems to not work since redismock thinks it should mock the firstScan
call as well, even though the key has not been set up to be mocked.An example in code:
Now if I mock the second call in my test suite like this:
redismock will return this error:
I'm using NewNiceMock to create my test client. Is there a way to set the mocking to be stricter, so that any calls that are not defined with the
.On
function will be completely ignored and not fuzzy-matched or whatever is happening here now?The behavior that I'm getting now is requiring me to mock both calls, which means that the first call can't use miniredis to get real data, which is of course not desirable.
The text was updated successfully, but these errors were encountered: