-
Notifications
You must be signed in to change notification settings - Fork 28
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
Type check for return values #46
Comments
@crisbodnar Agree. Unfortunately, I haven't found a way to do this yet. Any ideas how to change the DSL to make this possible? The problem is that In case we cannot make it a compile error, would you think that an improved runtime error message would help? What should it say? |
If you want to keep it in the exact style of Mockito I don't see any nice solution. The best thing I can think of right now is What do you think @petergtz ? |
@crisbodnar Yes, why not. We can introduce this as an alternative syntax and see how it works out in practice and potentially deprecate one of the syntaxes once it turns out one is superior to the other. I don't know when when I will have time to implement this. Are you interested in contributing this? I'd be more than happy to merge this as a pull request. |
Awesome. I wrote a design doc inside Improbable (https://improbable.io/) to switch to this mock library because it has type checks and it's much better than testify mocks in general (what we use now). Atm this is the only downside of this library. If we decide to do this switch (in the next few days) I am more than happy to implement this change. |
@crisbodnar Cool! Haven't heard of Improbable before, but will definitely have a closer look at it tonight. Would love to see guys adopting pegomock. |
@crisbodnar Any update on this? Just want to see if I can be of any help or so. |
Hi @petergtz. Sorry for the (very) late reply. Unfortunately, I am not working there anymore so not sure what the status is. |
@crisbodnar No worries. I will keep this issue open (in the Icebox), in case someone else would like to work on it. |
It would be useful to have a typecheck on the return value at compile time. Right now if I have
func smth(a int) int { //some code here }
I can safely write this without generating any compile time error:
When(struct.smth(1)).ThenReturn("Not an int", "One more invalid return value")
The text was updated successfully, but these errors were encountered: