-
Notifications
You must be signed in to change notification settings - Fork 46
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
validate dataProvider return/parameter types #152
Conversation
861a160
to
c8d5d0d
Compare
c8d5d0d
to
d889f5f
Compare
I'd like a completely different approach than this.
|
It may be important to note that |
I agree. With more and more complex method types, sometimes even conditional, it makes sense to actually not have any return type above data provider methods and infer the type from what the tests that require them expect. |
Well, I would say that if the data provider method defines its return type, it should be used by the check instead of inferring it (as other rules will validate that the returned values match this type). But inferring it automatically when the type is not defined (or is just |
Infered/accepting type (defined by accepting test method) should be always used. However, data provider type might be narrower, the infered/accepting type should be intersected with this type. |
I will re-evaluate based on the given feedback and start a new PR if I have something to review |
Closes #70