26 September 2007 - 1.7.6 | home user-guide eclipse jbossws intellij netbeans maven 1.X/2.X PDF files forums bugs sourceforge

Home
Getting Started
User Guide

- Overview
  - Tabbed Desktop
  - License Management
  - Preferences
  - XPath Selection
  - Script Library
- Workspaces
- Projects
- Interfaces
  - Interface Viewer
- Operations
- Working with Requests
  - Form Editor
  - Overview View
  - Outline Editor
  - Message Inspectors
  - Attachments/Inline Files
- Functional Testing
  - Getting Started
  - TestSuites
  - TestCases
    - Test Requests
      - Assertions
      - Editor Wizards
    - Property Transfers
    - Conditional Gotos
    - Groovy Scripts
      - Examples
      - GroovyUtils
    - Properties Step
    - Delay Step
    - Mock Response
    - DataSource
    - DataSource Loop
  - Property Expansion
- Load Testing
  - Getting Started
  - Limit & Strategies
  - Execution
  - Assertions
  - Diagrams
  - JMeter comparison
- Mocking
  - Getting Started
  - Mock Services
  - Mock Operations
  - Mock Responses
- Usage Scenarios
  - Data-Driven Testing
  - Template-Driven Testing
  - Interactive Testing
  - Surveillance Testing
- Tool Integrations
  - Code Generation
  - WSDL Generation
  - WS-I Tools
  - Apache Tcp-Mon
- CommandLine Tools
  - TestCaseRunner
  - LoadTestRunner
  - MockServiceRunner
  - ToolRunner
- Keyboard shortcuts

IDE/Tool Plugins
Search soapUI site
Project Documentation

- About soapUI
- Project Info
- Project Reports

## Groovy Script Library

soapUI Pro 1.7.5 introduces the possibility to have a central library of Groovy Classes that can be accessed from any script within soapUI, which can be usefull for centralizing common tasks/functionality and for creating soapUI extensions. Use as follows;

- Specify which folder to use in the soapUI Pro Preferences tab (default is <working directory>/scripts). soapUI Pro will check this folder for files with the "groovy" extension and compile these upon startup. The folder is then checked periodically (every 5 seconds) for updates and new/existing scripts are (re)compiled if neccessary.
- The compiled classes are added to the parent classloader of all groovy-scripts, you can access them as standard java classes.

Remember that the script files must be valid classes, not just arbitrary scripts.. see example below.

### Example

The following example is included with the soapUI Pro distribution, it consists of the following Greet.groovy file that is located in the default scripts folder:

    package soapui.demo

    class Greet
    {
       def name
       def log

       Greet(who, log)
       {
          name = who;
          this.log = log
       }

       def salute() { log.info "Hello $name" }

       def static salute( who, log ) { log.info "Hello again $who!" }
    }

If we create a Groovy Script Step in a TestCase, we can use the above class with the following:

    def greet = new soapui.demo.Greet( "Ole", log )
    greet.salute()

Running this from within the Groovy Editor will show (roughly) the following in the Groovy Editors log:

    Wed Jun 27 01:36:14 CEST 2007:INFO:Hello Ole

We can also call the static salute method:

    soapui.demo.Greet.salute( "Ole", log )

Which will produce the following output:

    Wed Jun 27 01:36:14 CEST 2007:INFO:Hello again Ole!

If we now modify the above Greet.groovy file and change the first salute method to include an exclamation mark at the end, soapUI will pick up the modified file (once it has been saved), which is seen in the soapUI log:

    Wed Jun 27 01:39:20 CEST 2007:INFO:C:\workspace\soapui-pro\scripts\Greet.groovy is new or has changed, reloading...

And now when we rerun our initial script we get;

    Wed Jun 27 01:40:16 CEST 2007:INFO:Hello Ole!

Next: Workspaces