Comment 1 James Synge 2007-03-20 08:40:06 EDT

Christof, you beat me to submitting this (I had it written up, just didn't hit submit until I'd had time for some more effort to repro).  My notes:

Build ID: I20070209-1006

Steps To Reproduce:
1. Run a test suite that has tests whose name is not the name of a method.
2. After the tests run, right-click on one of those tests
3. Select Run or Debug; this will produce the Assert failure shown below.

I can reliably reproduce this in my local environment with a test that used to be "re-runnable" in 3.3M4, but haven't yet figured out what it is about the JUnit test that is incompatible with the 3.3M5 JDT.  I wrote a focused little JUnit test where the names are not the names of the methods, and the problem didn't recur.  If you have any tips on how to further isolate this, I'll be happy to try to isolate.

Comment 2 Martin Aeschlimann 2007-03-21 07:42:15 EDT

Markus can you investigate if we find an easy fix for M6?

Comment 3 Markus Keller 2007-03-21 10:25:49 EDT

James, is there a good reason for creating test cases with non-standard names? This is just calling for trouble...

Here's a test to reproduce (run as JUnit Test, then rerun "my.Test"):

import junit.framework.*;

public class Bug178441 extends TestCase {
	public Bug178441(String name) {
		super(name);
	}
	
	protected void runTest() throws Throwable {
		fail("too bad");
	}
	
	public static Test suite() {
		TestSuite res= new TestSuite();
		res.addTest(new Bug178441("my.Test"));
		return res;
	}
}

Comment 4 James Synge 2007-03-21 11:20:44 EDT

Markus, yes, there is a good reason for the non-standard test names.  We're using EMF for modeling/generation of classes, and our own sub-system for persisting these objects in a relational database.  To test this persistence for each type, we have generic tests that will test a particular type, and this information is passed to the test via the name of the test (e.g. "testSave Type1" or "testUpdate Type3").

If we had a single "testSave" that tested all types in one run, then we wouldn't be able to re-run (debug) the test for a single type.

FYI, I did try your test case, and it failed as shown below:

org.eclipse.core.runtime.AssertionFailedException: assertion failed:
at org.eclipse.core.runtime.Assert.isTrue(Assert.java:109)
at org.eclipse.core.runtime.Assert.isTrue(Assert.java:95)
at org.eclipse.jdt.internal.core.SourceMethod.<init>(SourceMethod.java:34)
at org.eclipse.jdt.internal.core.SourceType.getMethod(SourceType.java:368)
at org.eclipse.jdt.junit.launcher.JUnitLaunchConfigurationDelegate.evaluateTests(JUnitLaunchConfigurationDelegate.java:258)
at org.eclipse.jdt.junit.launcher.JUnitLaunchConfigurationDelegate.launch(JUnitLaunchConfigurationDelegate.java:128)
at org.eclipse.debug.internal.core.LaunchConfiguration.launch(LaunchConfiguration.java:747)
at org.eclipse.debug.internal.core.LaunchConfiguration.launch(LaunchConfiguration.java:613)
at org.eclipse.debug.internal.core.LaunchConfiguration.launch(LaunchConfiguration.java:606)
at org.eclipse.jdt.internal.junit.model.TestRunSession.rerunTest(TestRunSession.java:298)
at org.eclipse.jdt.internal.junit.ui.TestRunnerViewPart.rerunTest(TestRunnerViewPart.java:1604)
at org.eclipse.jdt.internal.junit.ui.RerunAction.run(RerunAction.java:49)
at org.eclipse.jface.action.Action.runWithEvent(Action.java:498)
at org.eclipse.jface.action.ActionContributionItem.handleWidgetSelection(ActionContributionItem.java:545)
at org.eclipse.jface.action.ActionContributionItem.access$2(ActionContributionItem.java:490)
at org.eclipse.jface.action.ActionContributionItem$5.handleEvent(ActionContributionItem.java:402)
at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:66)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:938)
at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3490)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3104)

Comment 5 Markus Keller 2007-03-21 13:13:58 EDT

Unfortunately, rerunning tests with user-supplied names can only work if "Keep Junit running..." is checked in the launch configuration.

As soon as the target VM is down, there's no way to get hold of such tests any more. The best I can do is to avoid the exception and just show a dialog if the test method could not be found on rerun.

Comment 6 James Synge 2007-03-21 14:12:41 EDT

This worked fine in 3.3 M4 (and before).  I've been using it successfully for quite some time.  Something has changed in 3.3 M5 that broke this.  I suspect that what broke it is trying to use the test name as the name of a method, rather than leaving it up to Test.runTest to do that.

Comment 7 Markus Keller 2007-03-23 09:56:25 EDT

You're right, the only problem is that org.eclipse.jdt.junit.launcher.JUnitLaunchConfigurationDelegate.evaluateTests(..) assumes that JUnitLaunchConfigurationConstants.ATTR_TEST_METHOD_NAME can only contain a test method name, but in fact it contains the name of a TestCase, which can also be user-defined.

Since the test name is usually a method name and since evaluateTests(..) is already API, we don't plan to change this in jdt.junit. Filed bug 179011 for jdt.core to avoid the AFE.

Comment 8 Markus Keller 2007-04-30 08:34:14 EDT

Works fine in I20070430-0010.