Skip to content
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

Open
crisbodnar opened this issue Aug 19, 2017 · 8 comments
Open

Type check for return values #46

crisbodnar opened this issue Aug 19, 2017 · 8 comments

Comments

@crisbodnar
Copy link

crisbodnar commented Aug 19, 2017

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")

@petergtz
Copy link
Owner

@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 When is not generated and hence cannot return specific return values.

In case we cannot make it a compile error, would you think that an improved runtime error message would help? What should it say?

@crisbodnar
Copy link
Author

crisbodnar commented Aug 21, 2017

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
mock.When.smth(1).ThenReturn(1234)
and in this way we avoid the use of global methods like When which complicate any way of doing type checks. It's going to be only generated code.
I agree the When style is nice but we don't have generics :( and this is a significant improvement for the library. You can keep both versions in order not to break existent stuff.

What do you think @petergtz ?

@petergtz
Copy link
Owner

@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.

@crisbodnar
Copy link
Author

crisbodnar commented Aug 21, 2017

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.

@petergtz
Copy link
Owner

@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.

@petergtz
Copy link
Owner

@crisbodnar Any update on this? Just want to see if I can be of any help or so.

@crisbodnar
Copy link
Author

Hi @petergtz. Sorry for the (very) late reply. Unfortunately, I am not working there anymore so not sure what the status is.

@petergtz
Copy link
Owner

@crisbodnar No worries. I will keep this issue open (in the Icebox), in case someone else would like to work on it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants