Community
Participate
Working Groups
Build Identifier: 20100917-0705 Double-click on test method containing spaces in test pane results in 'method not found' message. Selecting method name containing spaces and pressing 'run' starts entire test class, not selected test method. Java method names containing spaces are valid and can be used by Groovy and/or frameworks like Spock http://code.google.com/p/spock/ Reproducible: Always Steps to Reproduce: 1. install eclipse groovy plugin http://groovy.codehaus.org/Eclipse+Plugin 2. create simple junit4 test with test method: void "test test"() {} 3. Run it and try to navigate to test method from junit pane.
Created attachment 193475 [details] Groovy JUnit4 test class illustrating the problem
Java method names <= 1.6 can *not* contain spaces, see JLS3 3.8. However, the class file format maybe supports that.
Yes, Java6 JVM allows spaces in method names: http://jcp.org/aboutJava/communityprocess/final/jsr202/index.html 4.3.2 Unqualified Names Names of methods, fields and local variables are stored as unqualified names. Unqualified names must not contain the characters '.', ';', '[' or '/'. Method names are further constrained so that, with the exception of the special method names (§3.9) <init> and <clinit>, they must not contain the characters '<' or '>'.
Since Java is not the only language used to write junit tests it could be good to support everything JVM supports.
*** Bug 443581 has been marked as a duplicate of this bug. ***
Created attachment 249022 [details] Patch to added support for method names with spaces I have created the attached patch which add support for selecting a junit test method that may have spaces in the name (i.e. spock tests) and opening the associated editor to the method.
Created attachment 249031 [details] Patch to added support for method names with spaces Oops, previous patch have some naming inconsistencies.
OK, it's been over a week. How about some commenting on the patch, please? You know a little "It's the best thing ever!", "My eyes can't unsee the horror of this patch" or even it's "just meh." Nonetheless, it the EF wants more contributors, we need interaction to help keep us going in the right direction.
(In reply to Wendell Beckwith from comment #8) > OK, it's been over a week. How about some commenting on the patch, please? > You know a little "It's the best thing ever!", "My eyes can't unsee the > horror of this patch" or even it's "just meh." Nonetheless, it the EF wants > more contributors, we need interaction to help keep us going in the right > direction. Sorry, we have a milestone this week and hence pretty busy with that. Stay tuned! Noopur, please review after M4 is out.
We won't add a preference for this. We rather have to understand the complete problem and then come up with a fix that just works fine in all cases. We should accept all characters that are valid as of the latest JVMS and then make sure we don't pass on non-Java method names if a consumer would throw exceptions. Check the bugs mentioned in OpenTestAction#extractRealMethodName(TestCaseElement) and make sure the new implementation doesn't break those cases. If we run into cases where we end up with multiple possible method names, then we have to try them all until we find an existing method. > // TODO How do I use the compliance levels to verify the jvm is 1.6+ The VM version doesn't matter. If you already have the method name, just try to work with it.
New Gerrit change created: https://git.eclipse.org/r/61579
I proposed a gerrit change but it is not working yet completely. The curren tissue is that in org.eclipse.jdt.internal.junit.ui.OpenTestAction.findMethod(IType), there is a check on JavaConventionsUtil.validateMethodName. In Eclipse, spaces in method names are not so it fails. I see several options: - remove the JavaConventionsUtil.validateMethodName , i think that there are no more real issue for that based on the very old commit and comment to related bug 127203. Launched AutomatedTestSuite and I have not more tests failing (yes I have 9 tests failing in my environment, need to take a look at that). - Remove space in method name before calling JavaConventionsUtil.validateMethodName (ouch it's crappy but it is the simplest solution) - Support spaces in Eclipse for method names --> seems to be a huge task Any thoughts? Other options? Which direction should we take to fix this issue?
A forth option would be to have access to the real method name. it seems that the codee causing the issue is due to the fact that the "getName" is overriden somewhere to have a better display (based on some comments). Need to search if this information is available or if it is loosed.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
