Summary: | [JUnit] Support UI extensions for custom runners | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | [Eclipse Project] JDT | Reporter: | Moritz Eysholdt <moritz.eysholdt> | ||||||
Component: | UI | Assignee: | JDT-UI-Inbox <jdt-ui-inbox> | ||||||
Status: | ASSIGNED --- | QA Contact: | |||||||
Severity: | enhancement | ||||||||
Priority: | P3 | CC: | daniel_megert, markus.kell.r, ryan.smith4 | ||||||
Version: | 4.3 | Keywords: | helpwanted | ||||||
Target Milestone: | --- | ||||||||
Hardware: | All | ||||||||
OS: | All | ||||||||
See Also: | https://bugs.eclipse.org/bugs/show_bug.cgi?id=546882 | ||||||||
Whiteboard: | |||||||||
Attachments: |
|
Description
Moritz Eysholdt
2012-10-03 10:50:36 EDT
Created attachment 221842 [details]
Example Screenshot for the theories runner
This extension would make it possible to solve the use cases of the following bugzillas via external plugins: Bug 343935 - [JUnit] JUnit test case with customized Runner, can't locate the method when it contains parameters after running Bug 200403 - [JUnit] Navigation support for JUnit theories Bug 338770 - [JUnit] Custom Runners cannot communicate file information I agree JUnit 4 tests with custom runners need more flexibility, and I agree with the set of requested features. We can consider such a contribution, but as you said, it would need quite some cleanup: - Its should be possible to write a UI extension without resorting to reflection and without accessing internal APIs. Implementations should use ITestElement and its subinterfaces. If more access is necessary (e.g. to open an element in an editor), then this needs to be added as a proper API. - The Eclipse SDK usually doesn't ship extension points / APIs it doesn't consume, so we should ship at least one working implementation that doesn't rely on internal jdt.junit classes (e.g. a cleaned-up version of the UI for Theories). hi Markus, thank you for the feedback. This is still relevant for me, since Xpect depends on it. I'd be willing to work on a contribution once I find the time for it. See: http://www.xpect-tests.org http://blog.moritz.eysholdt.de/2013/09/introduction-to-xpect.html http://www.eclipsecon.org/europe2013/executable-specifications-xtext-languages (In reply to Moritz Eysholdt from comment #4) > hi Markus, > > thank you for the feedback. This is still relevant for me, since Xpect > depends on it. I'd be willing to work on a contribution once I find the time > for it. > Let us know when you start. |