Community
Participate
Working Groups
JUnitLaunchConfigurationDelegate.getTestTarget looks like this: private final IJavaElement getTestTarget(ILaunchConfiguration configuration, IJavaProject javaProject) throws CoreException { ... String testTypeName = configuration.getAttribute(IJavaLaunchConfigurationConstants.ATTR_MAIN_TYPE_NAME, ""); if (testTypeName.length() != 0) { testTypeName= performStringSubstitution(testTypeName); ... } ... } private final String performStringSubstitution(String testTypeName) throws CoreException { return VariablesPlugin.getDefault().getStringVariableManager().performStringSubstitution(testTypeName); } The problem with this is that if I want to write a special version of JUnit Launch Configurations that determines main types an alternate way, I can't get to this private method. Alternatively, I recommend replacing all that boilerplate by calling this method from its parent AbstractJavaLaunchConfigurationDelegate: public String getMainTypeName(ILaunchConfiguration configuration) throws CoreException { String mainType = configuration.getAttribute( IJavaLaunchConfigurationConstants.ATTR_MAIN_TYPE_NAME, (String) null); if (mainType == null) { return null; } return VariablesPlugin.getDefault().getStringVariableManager().performStringSubstitution(mainType); } Please? :-]
Update: I have the same request for TESTNAME.
moving to JDT UI as well :)
(In reply to comment #0) > Alternatively, I recommend replacing all that boilerplate by calling this > method from its parent AbstractJavaLaunchConfigurationDelegate: > > public String getMainTypeName(ILaunchConfiguration configuration) throws Sounds good, can you attach a patch for this? (In reply to comment #1) > Update: I have the same request for TESTNAME. You mean a new protected method String getTestMethodName(ILaunchConfiguration)? Would be OK for me (in the same patch ;-).
Yeah, I can do that. :)
Created attachment 143312 [details] Uses parent class's getTypeName method.
Comment on attachment 143312 [details] Uses parent class's getTypeName method. That's not completely correct, since super.getMainTypeName(..) may return null, which leads to an NPE with your patch.
Created attachment 143320 [details] Uses parent class's getTypeName method. (attempt 2)
Thanks, released for next I-build.
Actually, your patch wouldn't even work for your scenario, since super.getMainTypeName(configuration) always executes the implementation in AbstractJavaLaunchConfigurationDelegate even if you overrode it in your subclass. I've fixed that for M2. Didn't you test your patch?
Mea culpa. I admit it. I could swear I left a comment asking where I could put a test, which, by the way, is no excuse. But worse, I can't find the comment! Arghghg. I'm really sorry, this is not the way I like to work. But seriously, where do tests for this plug-in go?
> I'm really sorry, this is not the way I like to work. Not a big deal, I just thought you already had client code that would use this. > But seriously, where do tests for this plug-in go? They are in the org.eclipse.jdt.ui.tests plug-in in the org.eclipse.jdt.junit.tests package. But I don't really need an automated test for this (the code is already executed by existing tests).
