Community
Participate
Working Groups
CONTEXT Create a parameterized JUnit 4 test, with some tests having the same name: [CODE] import org.junit.Test; import org.junit.runner.RunWith; import org.junit.runners.Parameterized; import org.junit.runners.Parameterized.Parameters; @RunWith(Parameterized.class) public class JUnitParameterizedTest { private final String parameter; public JUnitParameterizedTest(String parameter) { this.parameter = parameter; } @Parameters(name = "{0}") public static String[] getParameters() { return new String[] { "A", "B", "B", "C", "C", "C" }; } private static int callCount = 0; @Test public void test() throws InterruptedException { callCount++; Thread.sleep(100); System.out.println("Call " + callCount + " on " + parameter); } } [/CODE] Then run it. OBSERVED BEHAVIOR All tests are executed sequentially: [CONSOLE] Call 1 on A Call 2 on B Call 3 on B Call 4 on C Call 5 on C Call 6 on C [/CONSOLE] However, the JUnit view is broken: [JUNIT VIEW] JUnitParameterizedTest [Runner: JUnit 4] (0,406 s) - [A] OK (0,103s) - [B] - [B] OK (0,101s) - [C] - [C] - [C] OK (0,102s) [/JUNIT VIEW] It only shows information for the last instance of each. Moreover, the total time (0,406 s) is inconsistent with the individual tests (0,103+0,101+0,102=0,306). EXPECTED BEHAVIOR Since all tests are executed, all should have their respective information. Alternatively, although it might be a JUnit feature rather than an Eclipse one, it might be relevant to not execute several times the same test, since same inputs should lead to same output in unit tests. I don't go in the details of that since it is not the purpose here. In any case, the total time should be consistent with the details, either 0,306 s if we don't repeat or the actual sum of the 6 tests. -- Configuration Details -- Product: Eclipse 4.7.3.20180405-1200 (org.eclipse.epp.package.java.product)Installed Features: org.eclipse.jdt 3.13.4.v20180330-0919 Versioning Plugin: org.eclipse.platform 4.7.3.v20180330-0640
No bug. The Parameterized runner of junit4 considers the "name" value as identifier, according to its javadoc: https://github.com/junit-team/junit4/blob/master/src/main/java/org/junit/runners/Parameterized.java#L67. If you create multiple test cases with identical names and parameters, they are equals(): https://github.com/junit-team/junit4/blob/master/src/main/java/org/junit/runners/parameterized/TestWithParameters.java#L56, therefore it's not surprising eclipse cannot locate the correct entry anymore. Just use "{index} {0}" as name, and all is fine.
The documentation is not that strict: it says it serves to "easily identify the individual tests", not that it is used as an identifier (even less a unique one). Similarly, personal names help to identify people without the need for them to be unique. Moreover, if the interpretation was to use it as a unique identifier, I would expect some messages to be displayed in case of duplication, which is not the case. All tests are properly run without any exception nor warning. Additionally, I could find some interest in allowing non-uniqueness. At leat, just with the documentation and current behaviour, I am not convinced that they intend to have unique identifiers only. Would you have other resources to support this claim? I searched but failed to find concrete stuff on that matter, which is why I opened a bug.
I forgot the point of the equals(): it is not only on the name. It is also on the parameters themselves. So you may have the same name with different parameters instances (same toString(), but not equals()), leading to non-equal TestWithParameters instances.
My point about equals() being identical for your tests was a totally different one: Collection lookups are based on an equals() comparison for most collections. Therefore if the junit view executes code like treeviewer.indexOf(testCase) to locate the graphical control that needs to be updated with the test result, it will get the _same_ index for both testcase 2 and 3 (and also the same index for 4,5,6), therefore it is not surprising it updates only line per equal group of test cases.
Please correct me if I am wrong, but you are giving me the reason why the JUnit view does not manage tests having equal name & parameters. Right? It explains the observed behaviour, and thus makes a good start for fixing (if a fix is to be expected). Now, the execution goes through each of them, including duplicates. So there is a discrepancy between the execution (which considers also duplicates) and the view (which does not). It seems sound to me to align both, independently of the direction (fix the view or notify an unwanted use of JUnit).
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. If you have further information on the current state of the bug, please add it. 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.
The discrepancy is still present in Eclipse 2020-03 (4.15.0).
