Community
Participate
Working Groups
As test classes don't have to be public with JUnit 5 anymore, the class name == compilation unit name restriction has been lifted as well. This allows 'fancy' tests like the following, stored in "ExampleTest.java": import static org.junit.jupiter.api.Assertions.*; import org.junit.jupiter.api.Test; interface ExampleTest { @Test default void test() { assertNotNull(getInput()); } Object getInput(); } class ObjectScenario implements ExampleTest { @Override public Object getInput() { return new Object(); } } class StringScenario implements ExampleTest { @Override public Object getInput() { return new String(); } } Unfortunately, JDT (tested with Photon M4) doesn't handle them very well. 1. Run As > JUnit Test on the containing package: Executes both ObjectScenario and StringScenario (as expected) 2. Run As > JUnit Test on the ExampleTest.java compilation unit: Opens a test selection dialog for ObjectScenario and StringScenario. Selecting either results in a "The input type of the launch configuration does not exist" error. 3. Run As > JUnit Test on the ObjectScenario type: "The input type of the launch configuration does not exist" error again. IMHO, it would be nice if option 2 would simply execute both tests without asking (thus allowing users to easily their group tests by placing them in the same compilation unit. Also, option 3 should just work. After all, JDT can execute the tests just fine, as option 1 shows.
This happens because the IJavaProject#findType APIs being used everywhere in the jdt.ui code for JUnit do not consider the secondary types (types having names different than their compilation units). Example: JUnitLaunchConfigurationTab.getResolvedType(..). There are other IJavaProject#findType APIs available which can be used to include secondary types as well. But using those APIs will have bad performance issues and hence their use is discouraged. If this issue turns out to be a problem in regular usage by multiple users then we may consider using the other APIs for JUnit 5 only. The normal use case should generally have a single test class per compilation unit with the same name (with or without 'public').
(In reply to Noopur Gupta from comment #1) > If this issue turns out to be a problem in regular usage by multiple users > then we may consider using the other APIs for JUnit 5 only. Fair enough.
*** Bug 552537 has been marked as a duplicate of this bug. ***
This is a problem for me and several other users that use VS Code, see [1]. [1] https://github.com/microsoft/vscode-java-test/issues/859
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.
