RFR: 7903965: Fix Launching Tests from Context Menu [v6]

[Jorn Vernee]

On Tue, 11 Mar 2025 17:11:29 GMT, Oleksii Sylichenko <duke at openjdk.org> wrote:

>> Currently, there is an issue with running TestNG/JUnit tests when using the context menu on the editor tab. TestNG/JUnit intercepts the test execution from JTReg.
>> 
>> After fixing this issue, I decided to extend the fix to cover all potential use cases of the context menu.
>> 
>> As part of this pull request, I propose enhancing the process of running tests via the context menu. The context menu can be used in the following cases:
>> 
>> - Editor tab
>> - File in the project tree
>> - Directory in the project tree
>> - Any location within a file
>> 
>> The current changes automatically determine what needs to be executed:
>> 
>> - Directory
>> - File
>> - Method
>> 
>> Additionally, the issue with intercepting test execution through Application, TestNG, and JUnit configurations when using the context menu on the editor tab has been fixed.
>> 
>> # Summary
>> 
>> - Ensure that run configuration priority is no longer lost to Application, TestNG, or JUnit setups when launching via the context menu.  
>> - Fix run configuration created via the context menu: find and launch the proper test element, depending on the current PSI element.  
>> - Improve the logic for comparing existing run configurations with newly generated ones.  
>> - Add JUnit plugin in the dependencies.
>> 
>> # Detailed changes
>> 
>> ## Add JUnit plugin into dependencies
>> - build.gradle
>> - plugin.xml
>> 
>> ## Removed files
>> Merge the code of the directory and file config producers into a parent config producer.
>> - JTRegClassConfigurationProducer.java
>> - JTRegDirectoryConfigurationProducer.java
>> 
>> ## JTRegConfigurationProducer.java
>> - Refactor `setupConfigurationFromContext`:
>>   - Move the check for whether a file can be run to `JTRegUtils#isRunnableByJTReg`.  
>>   - Allow this method to create configurations for directories as well.  
>>   - Implement `preventRunPriorityLoss` to prevent priority takeover by other run configuration types (Application, TestNG, JUnit) under certain conditions.  
>>   - Replace the use of the current PSI element for generating names and querying run configurations with the specific element intended for execution.  
>> - Implement `preventRunPriorityLoss`.
>> - Add Javadoc for `nameForElement`.
>> - Fix logic in `isConfigurationFromContext` for checking if two configurations are identical:
>>   - Replace the use of the current PSI element for queries with the exact element intended for execution.  
>> - Compare string-typed configuration parameters using a "not-nullify" approach (`nu...
>
> Oleksii Sylichenko has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert: prevent configuration creation when multiple files or directories are selected

Great work! Just some minor inline comments

plugins/idea/src/main/java/com/oracle/plugin/jtreg/configuration/producers/JTRegConfigurationProducer.java line 112:

> 110:             element = findExactRunElement(element);
> 111: 
> 112:             configuration.setQuery(getQuery(element));

Suggestion:

            preventRunPriorityLoss(element, sourceElement);
            element = findExactRunElement(element);
            configuration.setQuery(getQuery(element));

plugins/idea/src/main/java/com/oracle/plugin/jtreg/configuration/producers/JTRegConfigurationProducer.java line 127:

> 125:      * The class {@link com.intellij.execution.actions.PreferredProducerFind} sorts the applicable runners using
> 126:      * {@link com.intellij.execution.actions.ConfigurationFromContext#COMPARATOR},
> 127:      * removing more general ones and retaining more specific or equal configurations.

The last line in this paragraph is a bit vague. The key issue here is that the IDE prefers config A over config B, if the `sourceElement` of A is nested somewhere inside B. So, we essentially use a hack here, by choosing one of the classes nested in the file that we are trying to run, so that we don't get beaten in the sorting order.

Just wanted to mention this for posterity. Maybe this could be called out explicitly:

Suggestion:

     * The class {@link com.intellij.execution.actions.PreferredProducerFind} sorts the applicable runners using
     * {@link com.intellij.execution.actions.ConfigurationFromContext#COMPARATOR}. This comparator prefers
     * configuration A over configuration B, when the source element of A is nested in B.

-------------

PR Review: https://git.openjdk.org/jtreg/pull/252#pullrequestreview-2675550972
PR Review Comment: https://git.openjdk.org/jtreg/pull/252#discussion_r1989829804
PR Review Comment: https://git.openjdk.org/jtreg/pull/252#discussion_r1989900387