Community
Participate
Working Groups
In case my test's name is "log on test (user peter)", the JUnit view will in the left window only show "log on test " leaving out the most interesting part.
David, can you have a look please.
Adjusting name
This is currently as-designed behavior. Any text in parentheses is assumed to be the name of the class in which the test is defined. A workaround could be to name the test "log on test [user peter]". You would get even better Eclipse integration by not overriding the getName method, and naming your test classes and methods informationally, like class LogOnTests public void testUserPeter() This would allow you to double click on failing tests and jump to their source in the editor. How important are the parenthesized names to you?
Actually I read the users from a file, so I can try many possible usernames (not all as this would take ages). It's kind of data driven approach so I can't name my method testUserPeter(), but testUsers(String name) which my TestSuite decompiles into my testUsers("Peter"), testUsers("James"), testUsers("Joe"), ... So right now I use the square-brackets workaround, but with parenthesis it looks more like the real methods. (square-brackets for arrays, curly braces for blocks, ...) I know this isn't hard-core JUnit, but except the bracket issue it integrates great.
This issue is still present, from 4.11 on Parameterized test will allow specifying a name that potentially may include parentheses so this becomes a JUnit core problem.
+1 to Marc's comment. With the new custom names in the Parameterized tests, names can contain arbitrary characters. I'm sure some exotic ones will need to be ruled out, but excluding parentheses and semicolons among others makes it very difficult to appropriately name certain types of tests.
Hello, I submitted a patch via Gerrit (https://git.eclipse.org/r/21766) with the following changes: - Fixed the problem where the test name would be cut after the first open parenthesis. - Fixed the action that opens the Java Editor at the test method location when the user double-clicks on a TestSuiteElement that corresponds to *single* parameterized test case, otherwise, added an action that expands the TestSuite to show all test cases that belonged to the test suite (ie, the tests that ran with the given parameter data) Please, let me know if it is OK for you of if it needs more work. Thanks Best regards, Xavier
Thanks for the patch. Did you double-check that changing the assumption/design (see comment 2) doesn't break anyone? Manju, please review, keeping the current design in mind.
Dani, Manju, I did some testing on existing JUnit tests and did not find any breakage, but please let me know if I missed something. Thanks.
(In reply to Xavier Coulon from comment #7) > Hello, > > I submitted a patch via Gerrit (https://git.eclipse.org/r/21766) I would prefer to have a patch attached to this bug than via Gerrit. TIA.
Created attachment 239824 [details] Patch proposal Patch proposal (similar to what was submitted via Gerrit).
Manju, I attached a patch to this issue, thus I'm reassigning this issue to you now. Thanks.
(In reply to Xavier Coulon from comment #12) > Manju, > > I attached a patch to this issue, thus I'm reassigning this issue to you now. > > Thanks. The assignee should always be the one who fixes/d the bug. Manju is marked as reviewer.
Dani, Sorry about that, I didn't know I should remain the assignee during the review process.
Thanks Xavier for the patch. Released the patch with the following changes: 1. Updated Copyright year and contribution details. 2. Replaced String comparison with Character comparison as the latter is efficient. 3. Removed ExpandTestAction as once this is in place double clicking on the test suite root does not activate the test file in editor but just expand the tree in the JUnit view. Released to master with : http://git.eclipse.org/c/jdt/eclipse.jdt.ui.git/commit/?id=93dbc808a9cef680d165b06045426ebbae285502
Thanks very much, Manju !
We use blocks in if-statements unless it's a trivial guard in the method's top-level block. Local variables should be declared at the latest possible place. indexOf(..) tests are not more efficient than starts/endsWith, and they are hard to read. If a character like ')' follows a URL, then there must be a space in between. TestElement#extractRawClassName(String): testNameString.lastIndexOf(')') can return -1 or something less than index+1. We better check for this. Fixed with http://git.eclipse.org/c/jdt/eclipse.jdt.ui.git/commit/?id=bef8ef7c3f64c21fad26ef437d13b1c8ab93da80
Markus, Sorry, I forgot to thank you for the feedback and improvements over my patch when it was merged earlier this year, but I guess it's never too late, so... thanks ! ;-)
