Failure in LibertyPluginSWTBotGradleTest.testDashboardDebugWithCustomConfigAction - widget not found

2023-09-08T19:44:40.2947775Z java.lang.RuntimeException: Unable to locate widget: Start parameters:
2023-09-08T19:44:40.2948419Z at io.openliberty.tools.eclipse.test.it.utils.MagicWidgetFinder.find(MagicWidgetFinder.java:1054)
2023-09-08T19:44:40.2949294Z at io.openliberty.tools.eclipse.test.it.utils.SWTBotPluginOperations.setCustomStartParmsFromShell(SWTBotPluginOperations.java:541)
2023-09-08T19:44:40.2950363Z at io.openliberty.tools.eclipse.test.it.utils.SWTBotPluginOperations.launchCustomDebugFromDashboard(SWTBotPluginOperations.java:523)
2023-09-08T19:44:40.2951532Z at io.openliberty.tools.eclipse.test.it.LibertyPluginSWTBotGradleTest.testDashboardDebugWithCustomConfigAction(LibertyPluginSWTBotGradleTest.java:428)

This failure was introduced by an earlier version of https://github.com/OpenLiberty/liberty-tools-eclipse/pull/428. It seemed to occur consistently on Linux in particular.

We decided to workaround the failure by configuring the tests to run in alphabetical order. Our guess is that the way to understand this fact is that the error is provoked by runningthe LibertyPluginSWTBotMavenTest tests before the LibertyPluginSWTBotGradleTest tests, and worked around when these are run in the opposite relative order, such that the Gradle tests are run first (it's conceivable there are other complicating factors, including possibly the other test classes).

Opening this issue to follow up on the failure, to understand it better. This will hopefully help us more generally under these SWTBot tests. It's not that running the tests in a predictable alphabetical order is necessarily bad, but we'd like to understand the failure while it's happening consistently, (as it was when merging the PR on top of the HEAD of https://github.com/OpenLiberty/liberty-tools-eclipse/commit/2fb4b6b2f3a87599c60e4571220eb593e5dd3cbe).

Start with LibertyPluginSWTBotGradleTest.testDashboardDebugWithCustomConfigAction and compare its execution with LibertyPluginSWTBotMavenTest. Trace SWTBotPluginOperations.launchCustomDebugFromDashboard, setCustomStartParmsFromShell, and MagicWidgetFinder.find around the reported failure, then reproduce the issue with different test orders. Done means the cause is understood and the tests no longer depend on the workaround ordering.