-
Notifications
You must be signed in to change notification settings - Fork 28
RC1 TCK: IdentityProcessorVerification §2.13 with primitive values #29
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
Comments
not sure I understand the problem, this test can't pass with int as type parameter since it can't be null, it will work if you use int? instead. Or is your issue that this test is executed for a value type at all? |
IMO the test shouldn't run for non-nullable types such as if (typeof(T).IsClass) {
// run the test
} |
But that could lead to implementations where this behavior isn't verified at all. Also what is the behavior on the JVM? The implementation calls onNext with null but how is that possible if int can't be null? |
The JVM doesn't have structs thus every type is a class (or interface) with a nullable reference. I found this that might help. |
I see, so if we change it, we could simply store the result of default(t) in a variable and check if it is null, i.e. var element = default(T);
if (element == null)
OnNext(element);
else
Ignore(); But I don't want to decide which option we take so I leave this for @viktorklang and @ktoso ;-) |
A third option would be to throw by default, including a more meaningful message and add a option to the TestEnvironment which can be used to skip those specs for value types. |
Not a .NET expert here, but I think it's fine to skip testing |
Yeah I guess so. |
If I test an
IProcessor<int, int>
implementation the testFails because
int
is non-nullable and the test possibly callsOnNext(0)
that is a legal value. The same impementation overIProcessor<object, object>
passes this particular test.The text was updated successfully, but these errors were encountered: