Workspace support for scripting

Hi Karel,

I am interested to know more about your ideas for this feature request.

For the first part (console to develop and execute generic Groovy/JavaScript scripts) - I know its not quite the same, but are you thinking something in the direction of the Groovy Console plugin:

https://github.com/olensmar/soapui-groovy-console-plugin (see the blog link for screen shots)

Is this anything like what you were thinking?

In terms of storing custom utility scripts, my approach has always been to use the extension classloader (/ext folder) and add my own jar files containing a Groovy API:

http://rupertanderson.com/blog/1-how-to-develop-add-and-use-a-custom-groovy-library-in-soapui/

The API methods can then be called across the various locations thus providing some degree of reuse and centralisation - but I imagine you probably already knew about this feature?

I had a feeling from your feature request that you were thinking of something more interactive? I know the Pro version had a script library feature, whereby it checked at intervals for news scripts and loaded them onto the classpath, but this is only really a slicker version of the above approach.

Thanks,

Rupert

Rupert,

the idea was to introduce a function to store and organize the scripts and a tool for their development/execution.

The libraries put into bin/ext folder are a good option, however with each change you need to develop/test/build/copy jar/restart SoapUI. I can do this e.g. from IDEA, but not from SoapUI. Moreover, I have to develop the libraries without SoapUI GUI and the environment I currently work with (open projects, test cases, their results etc.)

Development of groovy scripts from SoapUI GUI is more effecient as it is much more interactive.

I will check the Groovy Console plugin, I assumed it was deprecated, but 1.1 version should work with 5.2.1.

Thanks for your advice.

Karel

Hi Karel,

Thats interesting, you are of course right that the bin/ext approach is less dynamic / agile due to the need for compilation and restart.

I take it you're thinking about something more interactive? Have you seen the pro scripts functionality? That used to poll a /scripts folder and add any changed scripts dynamically into the classpath. This functionality could be replicated in the open source version, but I'm not sure if that would go down well with Smartbear (can't speak for them of course).

As you're probably aware, the key part of using scripted classes on-the-fly is getting them onto the SoapUI classpath without a restart, this is of course doable with a Groovy class loader type approach. Building on this idea, were you seeing some kind of UI functionality to edit/save scripts? Maybe a bit like the current Groovy TestStep, but instead having the ability to save the Groovy classes onto the classpath - I reckon something like this would be doable.

The Groovy console should work fine.

Thanks,

Rupert

KarelHusa,

I am second to you on this. However, it is possible to achieve this without waiting for this feature.

Like rupert_anderson mentioned in his first reply, using building custom library user have flexibility to choose different jvm languages such as groovy, java, and scala or even mix of them. Of course, it requires rebuild the library for any changes. If ant or batch scripts are created for the same(to compile, build, stop soapui, copy libraries and start soapui), which I do, it is easy to accommodate frequent changes faster rather doing the procedure manually.

Here, we have to note that, even if you use Ready API feature Script library: 

• Should there be a separate groovy script to be created(using the library script) or to execute for the common tasks that you mentioned?
• will that be going into a new test step in a project?
• Or just limited to Script library directory? If so, how that common script can be executed ?

Because, haven't used it.

Even now, if I were to do it, probably would create separate Utility SoapUI project for such need using Open Source edition. Haven't tried though.

• This project, obviously, do not have any wsdls, just utility scripts.
• Create test suite and further classify into different tests cases based on the specific need.
• Depending on the need, parameterize the test case, such as to accept project name etc  ( in case if needed to be updated other projects). May be have one specific script for each test case which would perform particular task.
• Would be a clean approach. 
• No duplicate of the common scripts.
• Do not have to copy the script into the project as a test step and which you do not want to do.
• Create scripts leveraging the custom library.

With this approach, the tasks you mentioned be achieved, IMO

- bulk change of a property within a project (or multiple projects)

[Rao]can be done

- launch several selected test suits

[Rao]can be done. In fact, I would prefer to use testrunner.bat/.sh to do this headlessly

- launch all test suits of selected projects

[Rao]Same as above.

- generate a test project from a list of WSDLs etc.

[Rao]can be done.

By the way, another strong feature of Pro is events which allows to execute some arbitrary script on certain event. And an extension has been create, is available for Open Source edition too. Refer here.

Couple of posts on the custom events :

http://stackoverflow.com/questions/37205952/soapui-increase-property-value-for-each-test-case/37209634#37209634

https://community.smartbear.com/t5/SoapUI-Open-Source/Testing-query-parameter-without-value-in-SoapUI-how-can-I-do/m-p/107017/highlight/true#M18471

https://community.smartbear.com/t5/SoapUI-Open-Source/How-to-add-addtional-HTTP-header-to-all-the-Rest-Requests/m-p/108768/highlight/true#M18724

https://community.smartbear.com/t5/SoapUI-Open-Source/Handling-a-SOAP-Fault/m-p/43840/highlight/true#M16984

Feel free to comments / questions / suggestions.