-
Notifications
You must be signed in to change notification settings - Fork 60
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
[575] junit-native does not support org.junit.rules.ExpectedException. #576
base: master
Are you sure you want to change the base?
Conversation
common/junit-platform-native/src/main/java/org/graalvm/junit/platform/JUnitPlatformFeature.java
Outdated
Show resolved
Hide resolved
} | ||
}; | ||
if (typeSafeMatcher != null) { | ||
access.registerSubtypeReachabilityHandler(registerMatcherForReflection, typeSafeMatcher); |
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.
How do we guarantee this does not affect user code by registering their classes?
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.
@vjovanov: Good question. I believe it's acceptable to register even the user classes. This is because subclasses of org.hamcrest.TypeSafeMatcher
and org.hamcrest.TypeSafeDiagnosingMatcher
that utilize the default constructor rely on Class.getDeclaredMethods()
to function properly. You can refer to TypeSafeMatcher#TypeSafeMatcher(), which indirectly invokes ReflectiveTypeFinder#findExpectedType(). Ideally, we would only mark the matchesSafely
method for getDeclaredMethods
, but unfortunately, this is not possible.
f5f1c11
to
01c5970
Compare
@fniephaus I've added the test |
Fixies issue #575 by registering all used subclasses of
TypeSafeMatcher
andTypeSafeDiagnosingMatcher
for reflective access to all declared methods.