I have three approaches for implementing tests for multiple projects:

Approach 1:
Open a parent directory containing two projects (one Maven and one Gradle). Use the tests written in the SingleModMPProjectTestCommon class. Create two additional child classes that inherit from the common class: one for the Gradle project and one for the Maven project.

• The Gradle project test class runs only on the Gradle project in the parent directory. Once the tests are completed, close the project.
• Then, run the Maven project test class, which executes tests only on the Maven project in the parent directory. After completing the tests, close the project.

NOTE: Same parent directory is open for both child test class run

Approach 2:
Open a parent directory containing two projects (one Maven and one Gradle). Create a new parent class and one corresponding child class(Common child class for both maven and gradle project). The child class passes an array of project names instead of a single project, which means the SingleModMPProjectTestCommon class cannot be used.

Use a for loop to execute each test against each project.
NOTE: This approach does not alter the test sequence. For example:

• Perform the Liberty Start action → Validate the project has started → Perform the Liberty Stop action on the first project.
• Then repeat the same sequence on the second project within a single test using the loop.

Approach 3:
Open a parent directory containing two projects (one Maven and one Gradle). Create a new parent class and one corresponding child class(Common child class for both maven and gradle project). The child class passes an array of project names instead of a single project. Modify the test code to perform simultaneous Liberty actions on each project.

NOTE: This approach alters the test sequence to enable simultaneous operations. For example:

• Perform the Liberty Start action on the first project → Perform the Liberty Start action on the second project.
• Validate that the first project has started → Validate that the second project has started.
• Perform the Liberty Stop action on the first project → Perform the Liberty Stop action on the second project.

Based on the discussion with the team, part of Approach 1 is sufficient: there should be two projects open in IntelliJ, but the tests need to run only against one of them.

Tests in SingleModMPProjectTestCommon

• testOpenBuildFileActionUsingPopUpMenu -> done
• testStartWithParamsActionUsingDropDownMenu -> done
• testStartWithParamsActionUsingPlayToolbarButton -> done
• testStartWithParamsActionUsingPopUpMenu -> done
• testStartWithParamsActionUsingSearch -> done
• testRunTestsActionUsingDropDownMenu
• testRunTestsActionUsingPlayToolbarButton
• testRunTestsActionUsingPopUpMenu
• testRunTestsActionUsingSearch
• testStartWithConfigInDebugModeUsingToolbar
• testStartWithConfigInDebugModeUsingMenu
• testStartWithConfigInRunModeUsingToolbar
• testStartWithConfigInRunModeUsingMenu
• testMultipleConfigEditHistory


• testCustomStartParametersClearedOnConfigRemoval

Enabled on os Linux only

• 

testStartInContainerActionUsingDropDownMenu
• testStartInContainerActionUsingPlayToolbarButton
• testStartInContainerActionUsingPopUpMenu
• testStartInContainerActionUsingSearch

I pushed my changes as part of this issue fix and I found that one test testMultipleConfigEditHistory
() was failing. During my investigation, I discovered that Liberty was not stopped because the wrong build file was chosen. This happened because there is a default selection in the dropdown list—for example, for a Maven project, it selects a Gradle build file.

I tried writing a code to select the exact build file from the dropdown list, but it didn't succeed because, as seen in the screenshot above, there is nothing to compare between the values in both lists—they are identical. We actually need the full path for both build files (one Gradle and one Maven).that is

/Users/home/intellij/repos/liberty-tools-intellij/src/test/resources/projects/multiple-project/singleModMavenMP/pom.xml

If we obtain the full path, we can compare it with the project name, singleModMavenMP, to validate the dropdown value. Build files are not always displayed in the "Liberty Project" dropdown in the same order, so we cannot pick the build file using indexing.. I am trying to get the full path to ensure accurate test results.
The affected tests are listed below.

1. testStartWithConfigInDebugModeUsingToolbar()


2. testStartWithConfigInRunModeUsingMenu()

Both the above tests uses method createLibertyConfiguration() , that is the reason it affecting the tests. Both the tests won't fail but it doesn't stop the Liberty Server and it leads to failure on test testMultipleConfigEditHistory()

https://github.com/vaisakhkannan/liberty-tools-intellij/actions/runs/12807359600/job/35707767143

While debugging, I found that the text (green-colored text) is not displaying the full build file path.

@TrevCraw , I tried various approaches to resize the Run/Debug Configurations dialog to a larger size in order to view the complete build file path, but I was unsuccessful. Then, I had a chat in the JetBrains Slack channel, and they shared code to resize the dialog window. I tried it, and it works, but it needs slight adjustments to properly display the complete path.

@TrevCraw , @dessina-devasia , I attempted to resize the Run/Debug Configurations dialog to a larger size to view the complete build file path. This approach was successful on macOS

It did not work on other operating systems. On Windows, the UI components are very large, and even after resizing the dialog window to a larger size, the build file path remained inaccessible.

NOTE: both resizeBottomRightand resizeTopLeft are working in windows, but the UI components are large in size.

On Linux, the dialog window could not be resized, preventing the build file path from being displayed.

NOTE: resizeBottomRight is not working in linux

I am considering resizing the dialog on macOS and Linux to retrieve the build file path successfully on both systems. For Windows, however, we may need to skip the tests that fail due to this issue (specifically, tests using the createLibertyConfiguration method).

Once you select an item from the list it appears in the text box and you can see the last segment of the name. Can you get the text of the currently selected item? You could loop through all of the items in the drop-down and select each one until you found the one you want.

@turkeylurkey , I tried to get the text from the currently selected item. But in that I couldn't see the last segment of the name.

When I reviewed the test code we currently have, I noticed that it doesn't exactly match the actual build file path; instead, it evaluates a condition.

activeCfgProjBldPath1 = (activeCfgProjBldPath1.endsWith("...")) ? activeCfgProjBldPath1.replace("...", "") : activeCfgProjBldPath1;

https://github.com/OpenLiberty/liberty-tools-intellij/blob/034fa100e27273a30a07772d2aa550c01032b3e0/src/test/java/io/openliberty/tools/intellij/it/SingleModMPProjectTestCommon.java#L932C13-L935C1

@TrevCraw , @turkeylurkey As an enhancement, I have a suggestion, though I'm not sure if it's acceptable. Can we add a fix in our code (not the test code) to display the project name first, followed by a colon, and then the build file path of the project?

Example:
singleModMavenMP: /Users/home/liberty-tools-intellij/src/test/resources/projects/multipleproject/singleModMavenMP/pom.xml

This fix would help retrieve the value more easily from the dropdown list by starting with the project name.

locator = byXpath("//div[@class='DialogPanel']//div[@class='ComboBox']");
        ComboBoxFixture projBldFileBox = addProjectDialog.comboBox(locator, Duration.ofSeconds(10));

        Keyboard keyboard = new Keyboard(remoteRobot);

        projBldFileBox.click();

        if (remoteRobot.isMac()) {
            keyboard.hotKey(VK_META, VK_C);
        } else {
            // linux + windows
            keyboard.hotKey(VK_CONTROL, VK_C);
        }
        try {
            String copiedValue = (String) Toolkit.getDefaultToolkit()
                    .getSystemClipboard()
                    .getData(DataFlavor.stringFlavor);
            System.out.println("Copied Value: " + copiedValue);
        } catch (Exception e) {
            e.printStackTrace();
        }

Copying and getting the combobox content using hotkey is working , I will try this instead of resize window

I'm surprised selectText() does not work since you see it on the screen but I'm glad you thought of the Ctrl-C trick.