---
title: Writing Groovy Script Libraries in SoapUI
description: How to write Groovy Script Libraries in SoapUI.
---

[Cegal tech blog ](https://www.cegal.com/en/tech-blog)

# [Writing Groovy Script Libraries in SoapUI](https://www.cegal.com/en/tech-blog/writing-groovy-script-libraries-in-soapui)

 Written by [Cegal Tech Advisors](https://www.cegal.com/en/tech-blog/author/cegal-tech-advisors) | Nov 23, 2018 8:11:00 AM

## Very often, when creating tests in [SoapUI,](https://www.soapui.org/) we end up writing a lot of [Groovy](http://groovy-lang.org/) code to add extra flexibility to our tests, create central or shared assertions, load files and data from disk or simply add an extra level of reusability to our tests. So this article is specially targeted towards API testers working with the [SoapUI](https://www.soapui.org/) tool by [SmartBear,](https://smartbear.com/) enabling them to reuse their [Groovy](http://groovy-lang.org/) code in various projects without resolving to the developer-hated copy-paste technique.

Although [SoapUI](https://www.soapui.org/) is a nice API testing tool that has quite extensive [Groovy](http://groovy-lang.org/) scripting support, it is not essentially designed to be used as a platform that facilities code development but rather as a declarative environment that enables test engineers to declare [Test Cases](https://www.soapui.org/docs/functional-testing/structuring-and-running-tests.html#1-Test-Structure) and assertions quickly. However, resolving to script capabilities is often inevitable when we have to load test data from a database, CSV files, etc., without resolving to the paid version of [SoapUI](https://www.soapui.org/). In a multi-project environment, in such cases, very often engineers have to resolve to copy+past technique when they want to apply the same [Groovy](http://groovy-lang.org/) code on different [SoapUI](https://www.soapui.org/) projects. One way to work around this problem is to write the shared code into the form of [JAR](https://en.wikipedia.org/wiki/JAR_(file_format)) library that can then be imported into different projects. However, this can be very impractical and demanding if our code references specific [SoapUI](https://www.soapui.org/) features or session information. So here we will see how to create shared code in a more [SoapUI](https://www.soapui.org/) native way.

## Developing shared Groovy Libraries

The process of developing shared [SoapUI](https://www.soapui.org/) libraries can be divided into the following steps:

1. Creating a shared project with common functionality,
2. Creating [Groovy](http://groovy-lang.org/) classes with library methods,
3. Defining library loading code in a project that is going to use a shared library,
4. Using shared library code in specific [Groovy Test Step](https://support.smartbear.com/readyapi/docs/soapui/steps/groovy.html).

## 1. Shared Project

The first step in developing a shared [Groovy](http://groovy-lang.org/) script library in [SoapUI](https://www.soapui.org/) is to create an ordinary [SoapUI](https://www.soapui.org/) project that will contain one or more [Test Suites](https://www.soapui.org/docs/functional-testing/structuring-and-running-tests.html#1-Test-Structure) that will contain one or more [Test Cases](https://www.soapui.org/docs/functional-testing/structuring-and-running-tests.html#1-Test-Structure) composed of [Groovy Test Steps](https://support.smartbear.com/readyapi/docs/soapui/steps/groovy.html).

Fig. 1. Example creating a shared project

## 2. Library Groovy classes

When we have defined [Groovy Test Steps](https://support.smartbear.com/readyapi/docs/soapui/steps/groovy.html) within the [SoapUI](https://www.soapui.org/) project that we wanted to share, we have to define a [Groovy](http://groovy-lang.org/) class containing methods that we want to reuse. We define one class for each [Groovy Test Step](https://support.smartbear.com/readyapi/docs/soapui/steps/groovy.html) we want to share. Class has to have a constructor that accepts: **log**, **context,** and **testRunner** parameters. These parameters are actually global objects defined by [SoapUI](https://www.soapui.org/) and made available to each [Groovy Test Step](https://support.smartbear.com/readyapi/docs/soapui/steps/groovy.html).

An example of such a constructor can be seen here:

```
 
```

This constructor gets [SoapUI](https://www.soapui.org/) global objects when initialized and used within another [Groovy Test Step](https://support.smartbear.com/readyapi/docs/soapui/steps/groovy.html).

Now we can define one or more reusable methods, and finally, we have to define an initialization block at the [Groovy Test Step](https://support.smartbear.com/readyapi/docs/soapui/steps/groovy.html) end, like in this example:

```
 
```

This block of code first checks if the object has already been initialized to assure singleton within the calling context, and if the object hasn’t been initialized then the object is created and registered as a property of the global [SoapUI](https://www.soapui.org/) **context** object. [SoapUI](https://www.soapui.org/) generates **log**, **context,** and **testRunner** objects for each test run.

So complete [Groovy Test Step](https://support.smartbear.com/readyapi/docs/soapui/steps/groovy.html) that contains a reusable [Groovy](http://groovy-lang.org/) class with public methods can look like this:

```

```

## 3. Library loading code

Now that we have defined the class and initialization block, we need a code that will run that block of code from another [SoapUI](https://www.soapui.org/) project and thus load classes that the current project will use. The current project shared library object loading block is best placed in its own disabled [Groovy Test Step](https://support.smartbear.com/readyapi/docs/soapui/steps/groovy.html) that can be placed in a specific **Initialisation** Test Case. This Test Case can contain initialization code for both local shared library code and global one.

An example of this organizational structure for the [SoapUI](https://www.soapui.org/) project can be seen in the following screenshot:

Fig. 2. Structure of the [SoapUI](https://www.soapui.org/) project that uses a shared library

The code in the InitLib [Groovy Test Step](https://support.smartbear.com/readyapi/docs/soapui/steps/groovy.html) gets the correct [SoapUI Workspace](https://www.soapui.org/getting-started/working-with-soapui/managing-workspaces.html) by using a globally available testRunner object. From that workspace object, the script is trying to get a shared library project object. The code works differently when the script is invoked from within the [SoapUI](https://www.soapui.org/) GUI environment, or when the script is invoked from the command line, or when running on the [Jenkins](https://jenkins.io/) server without GUI.

After assuring that the shared library project has been correctly opened (here again, the process is different when working within GUI or from the command line), the script executes the shared library initialization block (see [above](https://blog.sysco.no/testing/scriptlibrary-in-soapui/#library-groovy-classes)) and thus effectively creating a shared library class and storing the reference to it as a property of the **context** object.

The whole library loading code is given here:

```

```

## 4. Using shared library

Finally, in our project specific [Groovy Test Step](https://support.smartbear.com/readyapi/docs/soapui/steps/groovy.html) we can start using our shared library by invoking the following code:

```
 
```

This code first checks if the library has been loaded already (to assure singleton within the calling context), and then it loads the objects by running a shared library loading script that initializes all shared library objects and stores them in a map object that is available as a property of the **context** object.

## Conclusion

Unfortunately, [SoapUI](https://www.soapui.org/) [Groovy](http://groovy-lang.org/) support does not allow for easy [Groovy](http://groovy-lang.org/) code editing, debugging, and not to mention [Groovy](http://groovy-lang.org/) library creation. Thus, we have to stick to workarounds that use [Groovy](http://groovy-lang.org/) code to invoke other scripts that are residing in different projects within the same workspace. This workaround is not easy or straightforward to implement, but nevertheless, it allows us to have better [Groovy](http://groovy-lang.org/) script code reusability and, thus less error-prone code with minimal duplication.

```
 
```

[View full post](https://www.cegal.com/en/tech-blog/writing-groovy-script-libraries-in-soapui)

```json
{
  "@context" : "http://schema.org",
  "@type" : "BlogPosting",
  "author" : {
    "@type" : "Person",
    "name" : "Cegal Tech Advisors"
  },
  "dateModified" : "2023-11-28T18:41:44.188Z",
  "datePublished" : "2018-11-23T08:11:00Z",
  "headline" : "Writing Groovy Script Libraries in SoapUI",
  "image" : {
    "@type" : "ImageObject",
    "height" : 500,
    "url" : "https://7270560.fs1.hubspotusercontent-na1.net/hubfs/7270560/Tech-blog/Groovy%20soap%201000x500.png",
    "width" : 1000
  },
  "mainEntityOfPage" : "https://www.cegal.com/en/tech-blog/writing-groovy-script-libraries-in-soapui",
  "publisher" : {
    "@type" : "Organization",
    "logo" : {
      "@type" : "ImageObject",
      "height" : 60,
      "url" : "/hs/hsstatic/content_shared_assets/static-1.4092/img/default-amp-logo.png",
      "width" : 60
    },
    "name" : "Cegal tech blog"
  }
}
```