Groovy script tester in JMWE

Starting with version 5.0.0, the JMWE add-on comes with a Groovy script editor and tester in the post-function configuration screens. This document details the Groovy script tester, its availability, and features.

The Groovy script tester tool lets you test your written script against any issue. The main advantage of this tool is that you can quickly test and debug your script and make changes without having to actually trigger the transition and/or look at the Jira logs to see the result.

You can also choose to test your Groovy scripts or Groovy templates against selected Jira issues using the Groovy Console administrator functionality, without having to edit a Jira workflow.

On this page:

Groovy script tester availability

The Groovy script tester in JMWE is available on the:

  • The Groovy script editor in JMWE is available on the:

    • Post-function configuration screen when you select:

      • Groovy expression/Groovy Template as Value type in the post-functions that set a field value

      • Groovy expression/Groovy Template as Comment type in the post-functions that comment an issue

      • the Conditional execution option in any post-function

    • Post-function configuration screen of the Create/Clone issue post-function when you select:

      • Calculated as Project

      • Calculated as Parent issue

      • Set field value from Groovy or Set field value from Groovy template while setting a field in Set fields of new issue

      • Groovy expression/Groovy Template as Comment type while adding a comment to the current issue

    • Target issues section of all post-functions that operate on related issues when Issues returned by a Groovy script or Issues returned by JQL search is selected under Which Issues field.

    • Post-function configuration screen of the Email issue post-function while writing the Email content and recipients

    • Post-function configuration screen of the Link issues to the current issue post-function while writing the JQL search expression

    • Post-function configuration screen of the Unlink issues from the current issue post-function

    • Configuration screens of the Scripted (Groovy) conditionScripted (Groovy) validator and Scripted (Groovy) operation on issue post-function

    • Groovy Console admin screen that allows you to test/run Groovy scripts

    • Shared Groovy Scripts under JMWE administration

Using the Groovy Script tester

After writing your Groovy script in the editor, click on the Test Groovy Script button on the toolbar. A modal dialog window opens, asking you to pick an issue to run the Groovy script against, as well as a related issue, wherever applicable. 

Selecting an issue

You can select the issue from one of the following options:

  • Issue key: start typing an issue key, you will be offered options based on your issue browsing history
  • [Select issue]: if you click on [Select Issue], an Issue selector window gets displayed. You can select the issue either from:
    • Recent Issues: Displays issues that you have recently viewed and first 50 issues from your current search or
    • From Filter: Displays issues of your saved searches.

The issue variable used in your script will point to the above-selected issue. 

Selecting a related issue

In post-functions that process an issue’s related issues, after you select an issue (as explained above) in the tester, all issues related to it through the relation selected in Which issue(s) are displayed under Linked issue key. The relatedIssue variable and the deprecated linkedIssue variable used in your script will point to the selected related issue. For example: If the relation is the issues returned by the JQL search, the tester Linked issue key field will show issues that are a result of the JQL search.

In the post-functions that process the parent issue, after you select an issue (as explained above), its parent is displayed under Parent issue key. The parentIssue variable used in your script will point to the parent issue you select.

Testing your Groovy script

After selecting issue(s) against which the script should be tested (as explained above), click on Test. The following information will be displayed. This information can be used for 78057447.

  1. Message: Success/error message based on the test result.

  2. Result type: Data type of the result.
  3. Result value: Value of the result.
  4. Stack: If an exception was thrown during the execution of the script, a stack trace will be displayed.
  5. Logs: Information logged using the log variable.

Example

Test a script that fetches the username of the user the issue is assigned to:

  1. Add the Set field value post-function to a transition.
  2. Select Groovy expression as the Value type.
  3. In the Groovy editor, write the following lines of code:

    log.warn(issue.get("assignee").getName())
    return (issue.get("assignee").getName())
  4. Click on the Test Groovy Script button on the toolbar.
  5. Type an Issue key. The issue you pick must have a valid Assignee.
  6. Click on Test
  7. The following result is displayed:
  8. For the same script, select an issue which is unassigned and test the result (Repeat steps 4,5 and 6). Since the issue is unassigned, a null pointer exception occurs.

Debugging your script

If you encounter an error during testing, you will need to debug your script. The 78057447 information displayed in the script tester result panel aids in debugging the script.

Using the Message and Stack trace

In the above example, after testing the script against an issue that is unassigned:

  • Identify the problem, from the Message that displayed a null pointer exception error and the Stack that displayed the line number on which the error occurred.
  • Correct the problem, using the safe navigation operator ? that avoids the null pointer exception.

    return (issue.get("assignee")?.getName())
  • Retest the script, as 78057447 and verify the result in the script test panel. The result value will be null
Using the log variable

Using the log variable, you can debug your script, a step further, by adding information into the log. For example, while testing a condition, if the result evaluates to false when you expect it to be true, you might want to know what values are being compared in your condition. In such cases, you can use the log variable to display the value.

The log calls should always be used before the return statement because they would never get executed after it.

Consider the following script,

return (issue.get("assignee")? == "Scharlie")
  • Test the script, against an issue assigned to a user Scharlie. The script test would evaluate to false.

  • Identify the problem, using the log variable (as shown below) and check what values are being compared. 

    log.warn("Fetched user is" + " " + issue?.get("assignee"))
    return (issue?.get("assignee") == "Scharlie")

    Retest the scriptas 78057447 and verify the result in the script test panel. 

The script is comparing a user object to a String value.

  • Correct the problem, by fetching the username and then comparing the values

    log.warn("Fetched user is" + " " + issue?.get("assignee"))
    return (issue?.get("assignee").getName() == "Scharlie")
  • Retest the script, as 78057447 and verify the result in the script test panel. Now the condition evaluates to true.

  • Remove your logging code, so that log entries don't get written to Jira's logfile each time the post-function is executed.