-
Notifications
You must be signed in to change notification settings - Fork 3.3k
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
Allow custom test runners to create their own TestClasses and customize the scanning of annotations. #763
Conversation
@@ -25,7 +25,7 @@ | |||
* @since 4.5 | |||
*/ | |||
public class TestClass { | |||
private final Class<?> fClass; | |||
protected final Class<?> fClass; |
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.
I'd rather leave the field private, and have subclasses use getJavaClass(). Does that work?
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.
Absolutely. I didn't notice the getJavaClass() method.
Looks promising. |
Thanks for the pointer. I could squash these two commits if you'd like. |
Yep, if you can squash, I'll pull. Thanks! |
…ze the scanning of annotations.
done |
Allow custom test runners to create their own TestClasses and customize the scanning of annotations.
Thanks! |
@kcooney Thanks so much for checking. I'm having a bit of trouble following the new commit. If it helps, here is our custom test runner: https://github.com/motlin/eclipse-collections/tree/master/junit-trait-runner/src/main/java/org/eclipse/collections/impl/test/junit The only customization in the runner is to override the implementation of TestClass. And TestClass is overridden to change the behavior of scanAnnotatedMembers, so that it scans interface (default) methods that are annotated and call addToAnnotationLists on those. If there's a newer way to achieve the same goal, I'm happy to upgrade. |
@motlin that will continue to work after I merge that pull. Here's how someone would write that class in 4.13:
We will be deprecating |
@kcooney Sounds good, thanks. I still feel like our test runner's behavior would be good default behavior in JUnit 4. I haven't tried to promote our test runner and I realize this style of testing isn't common. But there's also little downside. The extra reflection code won't take much time since most tests don't implement any interfaces. We have a big and growing test suite here One nice example that shows the benefit is UnmodifiableListTestCase which inherits the tests for unmodifiable collections and for lists. The concrete tests that are classes are always small and usually implement one method which instantiates the collection under test, like UnmodifiableMutableListTest. Many, many tests live at the top of our trait hierarchy in RichIterableTestCase. |
@motlin JUnit 5 will support defining tests in default methods. |
This is to allow the creation of a test runner that looks for @test annotations on virtual extension methods in (Java 8) interfaces, as discussed on this closed pull-request.
You can see the test runner I built on these extensions here. It's a work in progress.