willis7/soapui-gradle-plugin

SoapUI Gradle Plugin

Gradle SoapUI plugin

The plugin provides tasks for running SoapUI tests and mocks during a Gradle build.

Unfortunately, I don't have much time to contribute anymore. In practice this means far less activity, responsiveness on issues and new releases from my end.

I am ctively looking for contributors willing to take on maintenance and implementation of the project. If you are interested and would love to see this plugin continue to thrive, shoot me a mail.

Build Status

Usage

This plugin has a fairly complex dependency tree. To use this plugin successfully we need to override some dependencies through forcing versions or completely substituting modules. See approach SmartBear uses solve jar-hell problem in their maven plugin. As a result your build file can look like this:

buildscript {
    ext {
        soapUIVersion = '5.3.0.RELEASE' // open source version
        // soapUIVersion = '5.1.2.PRO-RELEASE' // pro version
    }
    repositories {
        maven { url 'https://plugins.gradle.org/m2/' }
        maven { url 'http://www.soapui.org/repository/maven2/' }
        mavenCentral()
    }
    dependencies {
        compile("com.smartbear.soapui:soapui:$soapUIVersion") {
            exclude group: 'com.jgoodies', module: 'forms'
            exclude group: 'com.jgoodies', module: 'looks'
            exclude group: 'com.jgoodies', module: 'binding'
        }
    }
    configurations.all {
        resolutionStrategy {
            force 'com.jgoodies:binding:2.0.1',
                  'com.jgoodies:forms:1.0.7',
                  'com.jgoodies:looks:2.2.0'
        }
    }
}

apply plugin: 'io.byteshifter.soapui'

But for most common and trivial use-cases, buildscript configuration could be much simpler:

buildscript {
    repositories {
        jcenter()
        maven { url 'https://plugins.gradle.org/m2/' }
        maven { url 'http://smartbearsoftware.com/repository/maven2/' }
    }
    dependencies {
        classpath('gradle.plugin.io.byteshifter:soapui-gradle-plugin:5.3.0.RELEASE')
    }
}

apply plugin: io.byteshifter.plugins.soapui.SoapUIPlugin

Gradle Plugin Portal

Tasks

The soapui plugin pre-defines the following tasks out-of-the-box:

Task Name	Type	Description
soaptest	TestTask	Runs the SoapUI tests as specified by the plugin properties. Internally invokes the SoapUITestCaseRunner class as described there.
soapload	LoadTestTask	Runs the SoapUI loadtests as specified by the plugin properties. Internally invokes the SoapUILoadTestRunner class as described there.
soaptool	ToolTask	Runs the specified and configured code-generation tool. Internally invokes the SoapUIToolRunner class as described there.
soapmock	MockServiceTask	Runs the specified and configured code-generation tool. Internally invokes the SoapUIMockServiceRunner class as described there.

Task properties

soaptest properties

To configure the SoapUI test task you can choose to set the following properties within the test closure of the soapui extension:

• projectFile : Specified the name of the SoapUI project file to use
• testSuite : Specifies the name of the TestSuite to run
• testCase : Specifies the name of the TestCase to run
• endpoint : Overrides the service endpoint to be invoked by any TestRequests
• host : Overrides the target host:port to be invoked by any TestRequests
• username : Overrides the username used by any TestRequests run
• password : Overrides the password used by any TestRequests run
• domain : Overrides the domain used by any TestRequests run
• printReport : Controls if a small test report should be printed to the console (true/false)
• outputFolder : Set which folder results/reports are saved to
• junitReport : Turns on creation of JUnit-reports, (true/false)
• exportAll : Controls if all test requests should be exported (default only exports errors), (true/false)
• settingsFile : Specifies SoapUI settings file to use
• wssPasswordType : Specifies WSS password type
• projectPassword : Specifies password for encrypted project
• settingsFilePassword : Specifies password for encrypted settings file
• globalProperties : Sets global properties
• projectProperties : Sets project properties
• saveAfterRun : Saves project file after run
• testFailIgnore : Ignore failed tests.

loadtest properties

To configure the SoapUI load test task you can choose to set the following properties within the load closure of the soapui extension:

• projectFile : Specified the name of the SoapUI project file to use
• testSuite : Specifies the name of the TestSuite to run
• testCase : Specifies the name of the TestCase to run
• loadTest : Specifies the name of the LoadTest to run
• limit : Overrides the limit of executed LoadTests
• endpoint : Overrides the service endpoint to be invoked by any TestRequests
• host : Overrides the target host:port to be invoked by any TestRequests
• username : Overrides the username used by any TestRequests run
• password : Overrides the password used by any TestRequests run
• domain : Overrides the domain used by any TestRequests run
• printReport : Controls if a small test report should be printed to the console (true/false)
• outputFolder : Set which folder results/reports are saved to
• settingsFile : Specifies SoapUI settings file to use
• wssPasswordType : Specifies WSS password type
• projectPassword : Specifies password for encrypted project
• settingsFilePassword : Specifies password for encrypted settings file
• saveAfterRun : Saves project file after run
• threadcount : Number of threads in loadtest.

tool properties

• projectFile : Specified the name of the SoapUI project file to use
• iface : Specifies the interface to generate for
• tool : Specifies the tool(s) to run, a comma-separated list of axis1, axis2, dotnet, gsoap, jaxb, wstools, wsconsume, ora, wscompile, wsi, wsimport, xfire or xmlbeans
• settingsFile : Specifies SoapUI settings file to use
• projectPassword : Specifies password for encrypted project
• settingsFilePassword : Specifies password for encrypted settings file
• outputFolder : Set which folder results/reports are saved to

mock properties

• projectFile : Specified the name of the SoapUI project file to use
• mockService : Specified the MockService to run
• port : The local port to listen on, overrides the port configured for the MockService
• path : The local path to listen on, overrides the path configured for the MockService
• noBlock : Turns off blocking when MockRunner has started
• settingsFile : Specifies SoapUI settings file to use
• projectPassword : Specifies password for encrypted project
• settingsFilePassword : Specifies password for encrypted settings file
• saveAfterRun : Saves project file after run

Full Example

soapui {
    test {
        projectFile = 'sample-soapui-project.xml'
        testSuite = 'OleTest'
        printReport = true
        junitReport = true
    }
    load {
        projectFile = 'sample-soapui-load-project.xml'
        printReport = true
    }
    tool {
        projectFile = 'sample-soapui-tool-project.xml'
        iface = 'IOrderService'
        tool = 'wsi,axis1,axis2'
    }
}

Complex Example

There may be times when you have multiple test suites inside the same SoapUI project. You wouldn't want to maintain several Gradle projects, so the plugin uses convention mapping. This means you can have many tasks, but override the properties at runtime. Here's an example:

soapui {
    test {
        projectFile = 'sample-soapui-project.xml'
        printReport = true
        junitReport = true
    }
}

import io.byteshifter.plugins.soapui.tasks.TestTask

task testSuiteA(type: TestTask) {
    testSuite = 'SuiteA'
}

task testSuiteB(type: TestTask) {
    testSuite = 'SuiteB'
}

What you should notice in the example above is that we still use the soapui convention block with the nested test section. You may also have noticed that we have defined 2 new tasks of type TestTask. The TestTask is what runs the SoapUITestCaseRunner. The only difference between the 2 tasks is that they set their own value for testSuite. Through the magic of convention mapping the rest of the values are inherited.

Tons of TestSuites for enterprise-grade SoapUI test projects

In case of many TestSuites you might want use such approach to reduce a lot of duplications in your build script code:

[
    'SuiteA',
    'SuiteB',
    // ...
    'SuiteZ',

].each { suite ->
    tasks.create(name: suite, type: io.byteshifter.plugins.soapui.tasks.TestTask) {
        testSuite = suite
    }
}

Please, note: to run all of the TestSuites in this case, you can use only gradle soaptest command.

SoapUI test runner and plugin versions mapping

Previously, versions between soapui-gradle-plugin and SoapUI test runner was't synchronized. But after version 5.0.1 we will try to keep them synchronized as soon as newer SoapUI will be released.

soapui-gradle-plugin	SoapUI test runner
0.2	5.0.1
5.1.0	5.1.0
...	...
5.3.1-RC	5.3.1-RC
5.3.0.RELEASE	5.3.0

Using Open Source Version: We do recommend use SoapUI runner version 5.3.0 - it's last fully featured and quite stable version of SoapUI. Version 5.3.1-RC1 was not released. Version 5.4.0 is very limited: LoadUI integration has been removed. To create and run advanced load tests, use LoadUI Pro, which is part of the ReadyAPI application suite.

Contribute

• Issue Tracker: github.com/byte-shifter-ltd/soapui-gradle-plugin/issues
• Source Code: github.com/byte-shifter-ltd/soapui-gradle-plugin

License

The project is licensed under the MIT license.

soapui-gradle-plugin's Issues

Conventions do not get applied to custom test tasks

If I create a SoapUI test task of type TestTask, I expect that the conventions get applied to those tasks too. Currently that does not happen, thus I have to redeclare everything I already set by default in the soapui.test extension. Because the method that takes care of what I need is private in the plugin code, I cannot even reuse it.

Please also initialize extension properties designed to hold arrays with empty arrays so that we can just add values without having to remember whether the property is still null or not.

Missing Documentation for Configuration of Client Certificate Based Authentication

Hi, I'am trying to configure SSL Client Certificate Based Authentication. When using SoapUI I can do this like described in this link: https://blogs.sap.com/2011/01/06/soap-ui-tool-soap-https-client-authentication/
And that works also for me.

Unfortunately, when I'm trying to configure this via gradle it doesn't work. Specifically, it does not send the client certificate to server.

My configuration, which I tryed till now, looks like this:

soapUITest.projectProperties = ["clientAuthentication=true", "sslKeystore=${projectDir}/src/test/resources/mobileV2-test-certificates/mobileTest/mobileTest.p12", "sslKeystorePassword=********"]

Did someone try to set a client certificate for soap requests with this plugin? Is my configuration wrong?

Ragards,
Giacomo

"SoapUILoadConvention" misses "soapuiProperties"

> Could not set unknown property 'soapuiProperties' for object of type io.byteshifter.plugins.soapui.extensions.SoapUILoadConvention.

Compare that to SoapUIMockConvention and SoapUITestConvention which do have those properties.

This might apply also to SoapUISecurityConvention.

In addition to that, the documentation (README.md) does not mention soapuiProperties at all for any convention.

PS.: Consider a common class for reused properties?

Set outputFolder default to buildDir/soapui

To encourage a convention its better to place the outputs directly in the build folder of the project.

How to stop non-blocking mock service when using the Gradle daemon?

Hi,

I use the Gradle daemon, and I start a mock service like this:

soapmock {
	noBlock = true
}

How can I stop it once the SoapUI tests are finished?

Hint: There should be a Gradle task that has a way to access the runner...

Edit: I just realized these services seem to stop themselves somehow before restarting them, so there are no port conflicts... Or correct, me if I'm wrong...

Assertions fail but pass in the SoapUI application

Hi,

I'm trying to run existing tests using Gradle and your plugin. We have a custom namespace and a bunch of tests that run regularly and pass. When I try to run them through the plugin, the test is able to authenticate with the service and retrieve a valid response but the assertions fail. The assertions pass using SoapUI 4.5.2 and 5.3.0. The plugin uses 5.0.1. I haven't been able to test whether that's a factor.

Here's an extract from the response

  <sample xmlns:i="http://www.w3.org/2001/XMLSchema-instance" xmlns="<custom ns>">
     <id>2</id>
     <material_alias>Cold-Cold</material_alias>
     <material_id>23</material_id>
     <name>CT-000000023-0</name>
     <original_experiment_id>1</original_experiment_id>
     <priority>3</priority>
     <hazards>
        ...

and here are two of the assertions

            <con:assertion type="XPath Match" name="Sample exists">
              <con:configuration>
                <path>declare namespace ns1='<custom ns>';
exists(/ns1:sample)</path>
                <content>true</content>
                <allowWildcards>false</allowWildcards>
                <ignoreNamspaceDifferences>false</ignoreNamspaceDifferences>
                <ignoreComments>false</ignoreComments>
              </con:configuration>
            </con:assertion>
            <con:assertion type="XPath Match" name="Assert id">
              <con:configuration>
                <path>declare namespace ns1='<custom ns>;
/ns1:sample/ns1:id</path>
                <content>2</content>
                <allowWildcards>false</allowWildcards>
                <ignoreNamspaceDifferences>false</ignoreNamspaceDifferences>
                <ignoreComments>false</ignoreComments>
              </con:configuration>
            </con:assertion>

and here are the results

  ----------------- Messages ------------------------------
  [Sample exists] XPathContains assertion failed for path [declare namespace ns1='<custom ns>';
exists(/ns1:sample)] : RuntimeException: Trying XBeans path engine... Trying XQRL..
. Trying XDK... Trying delegated path engine... FAILED on declare namespace ns1='<custom ns>';
exists(/ns1:sample)
  [Assert id] XPathContains assertion failed for path [declare namespace ns1='<custom ns>';
/ns1:sample/ns1:id] : RuntimeException: Trying XBeans path engine... Trying XQRL...
 Trying XDK... Trying delegated path engine... FAILED on declare namespace ns1='<custom ns>';
/ns1:sample/ns1:id

Everything I've read says that the first slash before ns1 should be doubled. I've tried that both in Gradle and SoapUI and it hasn't changed things. I've also tried all sorts of variations, playing with namespaces, adding new assertions, etc. I can add new ones that pass in the app. I've been unable to add a single assertion that works in Gradle. I haven't been able to find where the plugin stores it's soapui jar to see if updating it would help.

I can't see any reason why these assertions should fail and, given that they pass in two versions of SoapUI, it does look like there's a bug somewhere. This is a blocking issue for me so any help will be appreciated.

Thanks.

Could not find com.smartbear.soapui:soapui:5.0.1

gradle clean test

FAILURE: Build failed with an exception.

* What went wrong:
A problem occurred configuring root project 'soap-ui-templates'.
> Could not resolve all dependencies for configuration ':classpath'.
   > Could not find com.smartbear.soapui:soapui:5.0.1.
     Searched in the following locations:
         https://plugins.gradle.org/m2/com/smartbear/soapui/soapui/5.0.1/soapui-5.0.1.pom
         https://plugins.gradle.org/m2/com/smartbear/soapui/soapui/5.0.1/soapui-5.0.1.jar
     Required by:
         :soap-ui-templates:unspecified > gradle.plugin.io.byteshifter:soapui-gradle-plugin:0.2

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output.

BUILD FAILED

plugins {
  id "io.byteshifter.soapui" version "0.2"
}

repositories { mavenCentral() }

version = "0.0.1"
description = "Tests"

apply plugin: 'io.byteshifter.soapui'

soapui {
    test {
        projectFile = 'AT-test-soapui-project.xml'
        testSuite = 'alphaTracker'
        printReport = true
        junitReport = true
    }
}

Test step properties question

Hello! I'd like to ask if the plugin allows users to specify specific properties to use for different test steps. Say, for example, We have test step A and test step B.

I want the plugin to run both A and B in succession, but use a header value X for test step A and a header value Y for test step B.

If this feature isn't yet supported, I am wondering if there will be any plans to add the support.

Thank you!

How to add jdbc driver to Soapui using soapui-gradle-plugin?

When using SoapUI, its possible to use postgresql driver in path=>SmartBear/SoapUI-5.4.0/bin/ext
But how and where to define the postrgresql driver for soapui-gradle-plugin?
Should it be done in soapui tests or should it be added to build.gradle as a dependency?

Not resolvable from JCenter

My builds can't seem to resolve com.lv.plugins:soapui-gradle-plugin:0.1 from jcenter. How can I get this to work?

Property Transfer failed

Hi,
I used this plugin to run my soap ui tests. I got the following error:
[com.lv.plugins.soapui.tasks.MySoapUITestCaseRunner] PropertyTransfer failed, exporting to ...

I could run my tests successfully in Ready! API 1.4.0.

Could you please provide your input on this?

Below is my build.gradle:

// Apply the java plugin to add support for Java
apply plugin: 'java'
apply plugin: 'com.lv.soapui'

task wrapper(type: Wrapper) {
gradleVersion = '2.3'
}

// In this section you declare where to find the dependencies of your build script
buildscript {
repositories {
mavenLocal()
//This repository contains the missing dependencies
maven {
url "http://repo1.maven.org/maven2/"
}
maven {
url "http://www.soapui.org/repository/maven2/"
}
}
dependencies {
classpath 'com.lv.plugins:soapui-gradle-plugin:0.1'
}
}

repositories {
mavenCentral()
mavenLocal()
}

dependencies {

}

soapui {
test {
projectFile = 'Project-name-soapui-project.xml'
printReport = true
junitReport = true
testSuite = 'TestSuite 1'
}
}

Thanks!

new tasks only available when project.xml given

When the 'soapui' plugin is applied to the project, tasks should only be available once the project.xml is provided. This will avoid the need to throw an exception later on.

Dangling JVM process after integration test

When the integration tests are run I can see Java processes are left hanging using ps -fe | grep java. These processes need to be cleaned after execution.

soapui-gradle-plugin:5.1.2.PRO-SNAPSHOT

Hi,
Thanks for your pro plugin.I used it in my local machine first time I got error like "Missing folder for external libraries" and "Missing scripts folder",then I tried one more time Its ran successfully.

But when I run my app in jenkins I got above error continuously.

Thanks

Typo in TestTask.groovy

Hello,

There is a typo in the soapui-gradle-plugin. In src/main/groovy/io/byteshifter/plugins/soapui/tasks/TestTask.groovy, line 219, projectProperties() should be getProjectProperties().

This causes the setting of the projectProperties key in the soapui -> test closure to throw a NullPointerException.

The fork at [https://github.com/creising/soapui-gradle-plugin] is also affected.

Document Multiple tasks

This issue is in response to the note left on issue #1 :

Hi , I want to drive the build.gradle to multiple project files with for each project file has a list of properties, I tried my self hard , like applying the below code could you please assist me how to achieve that .

original soapui test extension object

 soapui{ 
   test {
        projectFile = 'src/ABC.xml'        
        testSuite = [ 'INTEGRATION_SUITE']       
        printReport = true
        junitReport = true
        outputFolder = 'out'
        globalProperties = 'ServiceEndpoint=localhost:7201'
        endpoint = 'http://localhost:7201'
        testFailIgnore =true
    }

    }

i tried the following. drive through the below map , map contains projectFilename as key and list of test suites as value

def map = [ 'project1':['assertProject.xml',['A','B','C']],'project2':['assertProject.xml',['A','B','C']],'project3':['assertProject.xml',['A','B','C']]           ]

soapui {


 map.count{ mit->  test {myit->

        projectFile = 'src/${myit.key}'        
          testSuite = ${myit.value}      
        printReport = true
        junitReport = true
        outputFolder = 'out'
        globalProperties = 'ServiceEndpoint=localhost:7201'
        endpoint = 'http://localhost:7201'
        testFailIgnore =true
    }
    }
    }

Hi

Can I use this for SOAPUI Pro project

is it possible to run several "soapmock" tasks

I need to run several mock servers, i am using your plugin, It's not a problem to run 1 "soapmock" task,
Is it possible to run several with different ports or hosts