Is there a simple way to test scriptRunner postfunctions, conditions and validators

[Vasiliy Zverev]

It takes a lot of time to develop same groovy script. The longest part is to test some script. I need to

1. modify a workflow
2. publish it
3. open issue
4. make a transition
5. try to find any mistaks.

Does any knows any way to simplify these steps?

[Jeremy Gaudet · Accepted solution]

If you can get shell access to JIRA, step 5 is easier because then you can look at the logs for exceptions to help identify the mistakes.  Failing that, what I've done to debug issues is to code them into a validator, and output the value of variables as the payload of an InvalidInputException, either to debug the value directly, or to use it as a checkpoint to identify how far along the code is getting before failing.

Beyond that, the "Simple Scripted Condition" script-runner condition has a preview option that replaced the "condition tester" built-in script.  This lets you evaluate code against a sample issue and see if it returns true or false against that issue.  You can use this to test complicated validators by moving around a "passesCondition=true" statement to where you would normally set invalidInputException.  For post-functions, it would probably let you test the framework, but not the actual side effects.

To test side effects for a post-function, if you are a JIRA admin you can access the script console and input the script there.  You'll have to make modifications to pick up the issue you want to run against, but it's a start.  For example:

import com.atlassian.jira.ComponentManager;
import com.atlassian.jira.issue.IssueManager;

IssueManager issueManager = ComponentManager.getInstance().getIssueManager();
Issue issue = issueManager.getIssueObject("ABC-12345");

Here I was doing side effects on the sub-tasks, and so I didn't need a MutableIssue.

[Vasiliy Zverev]

Thank you for detailed answer

[JamieA]

@Jeremy Gaudet has given a great answer, but I'll add a few extra bits.

It sounds like @Vasiliy Zverev is using inline scripts. These will take a long time because you need to publish the workflow every change. I always point to script files, then once you've set up the workflow you can keep editing and then just redo the transition.

I appreciate not all admins have filesystem access, but it's worth spending the time to set up a local dev instance, then you can paste in your scripts when you're done, or better still get someone to put them on the JIRA server filesystem (or clone/update a git repo). There are multiple ways to do this, here is one.

I have a test project, with a test workflow that has a load of different workflow functions, that I can just use to test any particular thing.

If you can't get logs access directly, and you definitely will need them at some point, you can use Built-in scripts -> View Server Logs.

Regarding the tip about using script console, you can use this structure:

import com.onresolve.scriptrunner.runner.customisers.ContextBaseScript

@BaseScript ContextBaseScript contextBaseScript
Issue issue = getIssueOrDefault("JRA-2884")
...

This will use the issue supplied in the binding, or if not present (because you're using script console) it will use the key supplied. So you can use the same script in either context.

It should also be possible to run a script which reads the code to run from a URL, eg from a local webserver running on your workstation. But this could pretty dangerous so I won't expand on that further.

If you want to take a test-first approach you could look at https://scriptrunner.adaptavist.com/latest/jira/testing.html, but this requires more commitment, and filesystem access.

Finally, getting feedback from running scripts is at the forefront of my mind at the moment. The next version aims to let people have more insight, eg script console:

image2015-12-15 20:49:10.png

For workflow functions, script fields, etc, you get the last run history, clicking on one of these will show the logs, payload and timing info in a dialog:

image2015-12-15 20:53:25.png

[Vasiliy Zverev]

Thank you, I'll see this aproach

[Vasiliy Zverev]

Also it is possible to return value from unkine script like this

import com.atlassian.jira.ComponentManager;
import com.atlassian.jira.issue.IssueManager;
 
IssueManager issueManager = ComponentManager.getInstance().getIssueManager();
Issue issue = issueManager.getIssueObject("ABC-12345");
 
//It will be displaied
return issue.getKey()

[Bob Swift OSS (Bob Swift Atlassian Apps)]

If you want a repeatable test, then GINT - Groovy Integration Test Framework can be used with specific support for JIRA. All of our workflow add-ons are tested this way.

If you just want some automation help with your manual tests, then JIRA Command Line Interface (CLI) can make help (like createIssue, transitionIssue, getIssue).