-
Notifications
You must be signed in to change notification settings - Fork 4.9k
Add tests for calling Span APIs via reflection to verify graceful failures. #28674
Conversation
Assert.Throws<TargetException>(() => ctor.Invoke(new object[] { new int[10], 1, 1 })); | ||
|
||
ctor = type.GetConstructor(new Type[] { typeof(void*), typeof(int) }); | ||
Assert.Throws<TargetException>(() => ctor.Invoke(new object[] { null, 1 })); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Anything to validate about the TargetException's inner exception?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What should we validate about the inner exception? That it is null?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If the inner exception is null, then nevermind. I thought TargetException is often thrown from reflection when it's wrapping another exception, but maybe that's only true of TargetInvocationException?
{ | ||
Type type = typeof(MemoryExtensions); | ||
|
||
MethodInfo method = type.GetMethod("AsSpan", new Type[] { typeof(string) }); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we use nameof(MemoryExtensions.AsSpan)
instead of manually typing the string? Same question for the rest of these.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What about methods like op_Equality?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Basically use nameof wherever you can. If you can't use it in some circumstances, then don't 😄
It is overkill to have the tests for all methods on Span. You should have just one method per interesting category:
|
I didn't add tests for all the methods. But I do see some duplication of the MemoryExtensions static methods. I can remove some of those.
|
It would be useful to name the tests based on the interesting category that they are testing, not based on the method name that they happen to use to test it. |
Thanks! |
You will need to disable these tests on netfx. |
…lures. (dotnet/corefx#28674) * Add tests for calling Span APIs via reflection to verify graceful failures. * Add Span reflection tests to verify graceful failures * Address PR feedback (test cleanup and rename) * Fix up some test names * Minor tweak: Reorder the tests * Exclude running the reflection tests for portable span (netfx) * Remove unused constant from csproj Commit migrated from dotnet/corefx@a7b59b0
Partially resolves https://github.com/dotnet/coreclr/issues/17296
cc @jkotas, @atsushikan, @KrzysztofCwalina