Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 338770

Summary:	[JUnit] Custom Runners cannot communicate file information
Product:	[Eclipse Project] JDT	Reporter:	Matt Fowles <matt.fowles>
Component:	UI	Assignee:	JDT-UI-Inbox <jdt-ui-inbox>
Status:	ASSIGNED ---	QA Contact:
Severity:	enhancement
Priority:	P3	CC:	markus.kell.r, moritz.eysholdt
Version:	3.7	Keywords:	helpwanted
Target Milestone:	---
Hardware:	PC
OS:	Linux
Whiteboard:

Description Matt Fowles

2011-03-02 22:48:51 EST

Build Identifier: 20100218-1602

JUnit4 provides custom test runners.  These custom test runners often generate tests (with descriptions) based on resources that are not .class files (for example xml test descriptions or directories in a project).  The JUnit view will correctly list such tests based on the Description[1] that the runner generates; however, double clicking on the test will always produce an error[2].  It would be better if the JUnit view accessed a file and location to open based on a standardized annotation on the description and only fell back to searching methods if they weren't present.

Obviously, this would require collaboration between the JUnit team and the eclipse team.  The JUnit folks already have a ticket[3] for this and are eager to collaborate.

[1] http://kentbeck.github.com/junit/javadoc/latest/
[2] Method '<description name>' not found.  Opening the test class.
[3] https://github.com/KentBeck/junit/issues/43

Reproducible: Always

Steps to Reproduce:
Project Lombok is an example of a project with a custom runner.

1. Grab lombok from https://github.com/rzwitserloot/lombok
2. run `ant eclipse`
3. import the project in eclipse
4. Run TestWithEcj as a JUnit4 test
5. Try double clicking on any of the tests that it runs.

Comment 1 Markus Keller

2011-03-03 07:07:40 EST

We're open for enhancements, but we don't have the resources to implement this on our own.

Note that JUnit tests run in a separate VM and we have a wire protocol that shuffles information from the test VM back to Eclipse (RemoteTestRunner/RemoteTestRunnerClient), so if we have to look at annotations on a Description, that will require bigger changes. I don't even know if that would be feasible, since Descriptions are sometimes re-created in JUnit and I not sure the annotations survive that (e.g. Description#equals(Object) doesn't care).

If this is just about using a different mechanism to open a test method that still uses Description#getTestClass() but replaces Description#getMethodName(), then things are probably a lot easier, since we can implement everything on the client side in org.eclipse.jdt.internal.junit.ui.OpenTestAction. I.e. find the type using existing code and then using IType#getAnnotations() to find out what file to open.

Comment 2 Matt Fowles

2011-03-03 11:38:48 EST

Trying to keep this in sync with the ticket on JUnit.  My suggestion runs as follows:


Currently the UI uses:

Description.getTestClass()/Description.getClassName() -- not sure which
Description.getMethodName()

which is unfortunately very specific to a JUnit class runner.  I would suggest adding

Description.hasCustomLocation()
Description.getFileName()
Description.getLineNumber()

where the first method indicates that the other two should be used.

Comment 3 Moritz Eysholdt

2012-10-03 10:56:28 EDT

see also Bug 391023