Are you for a hot cup?

How to mock REST Service In soapUI

noreply@blogger.com (ddd) — Sun, 10 Mar 2013 20:46:00 +0000

-------------------------------------------------------------------------------------------------------------

Book Groovy for soapUI users will be available soon. More information on this page.

-------------------------------------------------------------------------------------------------------------

Problem

soapUI is mostly about SOAP protocol and by SOAP definition you need WSDL( Web Service Description Language ) file for particular web service you are working on. That would be service definition or contract that specifies client-server conversation. Existence of service definition allows soapUI to easy and automatically create service mock.

In case of REST service situation is quite different. REST is not protocol, it is architectural style or paradigm which relies on HTTP protocol. WADL ( Web Application Description Language ) file can be used to describe REST web service but it is not necessary. Actually in many cases service publisher do not have WADL file, just documentation describing service resources and parameters. This makes REST automatically mocking quite a challenge.

Static REST mocking

For this you need several responses and create folder where you will those store responses. Create empty soapUI project and then add one mock service. Open it and configure it:

Important things here are:

Path - this would be base path for mock service
Port - port on which mock service works. Be sure it is not used by any other service.
Docroot - root directory where responses will be searched for.

Other settings are not necessary and they can be left not set.

Now if you open your browser and go to http://localhost:8089/test you should get this:

OK, mock service is working but we need to add some responses. You do not need to stop service just in docroot folder add new folder named user and create file response_one.json. I put simple text in response file, it do not need to be JSON. Then when go to http://localhost:8089/test/user/response_one.json you should see something like this:

So to add another response you need to create file and store it in docroot or its sub folders. When sending request you need specify path to response. This is quite simple but rather limited:

You need to create file structure that look like REST resources and store responses in files.
This only work with GET HTTP method
This do not support parameters in request. Links like : http://localhost:8089/test/find?user=test will not work unless you make file named find?user=test which could be problematic based on OS you are using.

One small advice instead setting static value for docroot use relative value from project file for example:

${projectDir}/REST Example.

Dynamic REST mocking

As already mentioned REST relies on HTTP protocol. That means service provider can use all HTTP methods ( POST, GET, PUT, DELETE, HEAD, TRACE, OPTIONS, CONNECT and PATCH ). Most of the time only POST, GET, PUT and DELETE are used as they are CRUD ( Create, Read, Update and Delete ) operations.
Obviously best way to achieve this in soapUI is to use Groovy. If you look at Mock service panel you can notice OnRequest Script tab:

This a place where I can put my Groovy script to handle incoming requests to mock service. First thing I would like to be able to support any non POST request. Reason as I already mentioned is that soapUI mock service by default support only POST requests, but they also can be handled with Groovy scripts. To do that we can use this snippet:

if ( mockRequest.method == "GET" ) {
....
}
if ( mockRequest.method == "PUT" ) {
...
}

mockRequest is mock service variable available in OnRequest Script and represent incoming request. Checking its property method you can determine which HTTP method is used for request.

Next thing I need to determine is path. Path would be part of URL that determine path to some service resource relative to base URL. If service base URL is http://www.example.com/rest/ and service have several operations like get user, add user etc. then URLs to them can be: http://www.example.com/rest/adduser, http://www.example.com/rest/getuser, etc. In these cases paths are adduser and getuser. Those paths tells me what service method is to be used. Again to get path I can use mockRequest variable:

def path = mockRequest.getPath()

Some service methods or resources can have or require one or more parameters. For example, this GET request:

http://www.somedomain.com/service/getuser?id=121

Method getuser will return user but it need to be told what user you need. To do that client specify parameter id with unique user id value. In this case id is parameter and 121 is passed value. In above example there is only one parameter in request but there could be much more, like:

http://www.somedomain.com/service/adduser?nick=tito&name=tata&last_name=roro

In this example there are three parameters: nick, name and last_name. String that comes after ? is parameter string. To get is value you can use:

def queryString = mockRequest.getHttpRequest().getQueryString()

If we put above all together:

def path = mockRequest.getPath()
def queryString = mockRequest.getHttpRequest().getQueryString()
if ( mockRequest.method == "GET" ) {
if( path == "getuser" ) {
// anallyze parameters and create response
// send response
}
// handle other paths here
}
if ( mockRequest.method == "PUT" ) {
if( path == "update_user" ) {
// anallyze parameters and create response
// send response
}
...
}
if ( mockRequest.method == "DELETE" ) {
if( path == "delete_user" ) {
// anallyze parameters and create response
// send response
}
...
}

This would be basic boilerplate for REST mocking with soupUI. Analysing parameters are quite simple and basic stuff. Response creating is simple if you use XML or JSON builders from Groovy. Sending response can be tricky part. From soapUI documentation this is used:

mockRunner.returnFile(mockRequest.httpResponse, new File(responseFolder, "response_file.json") )
mockRequest.httpResponse.setContentType("application/json;charset=utf-8")
return new com.eviware.soapui.impl.wsdl.mock.WsdlMockResult(mockRequest)

From this means you have to save response in some file and then use it to send response. In example above response is in JSON format. That is can be changed to XML or any other format you need. If you write response to some file and then use:

mockRunner.returnFile(mockRequest.httpResponse, new File(responseFolder, "response_file.json") )

Than all is fine. But if you construct response and convert it to String then you can use this code instead above line:

def response = "Some response as String"
InputStream in = new ByteArrayInputStream(response.getBytes())
response.setStatus( HttpServletResponse.SC_OK );
long length = response.length();
response.setContentLength( ( int )length );
response.setContentType( "set content type here" );
Tools.readAndWrite( in, length, response.getOutputStream() );
in.close();

This will put response string in response object and it will be shipped back to client.

stoolz: soapUI helpers

noreply@blogger.com (ddd) — Tue, 25 Sep 2012 09:30:00 +0000

Goal

Idea is to increase learning curve of soapUI API. stoolz will try to hide all boilerplate you usually need to do for simple tasks.

Run Context Wrapper

RunContextWrapper is helper that wraps run context in attempt to make accessing to its properties, test steps, test case, test suites, project and workspace easier.

Examples

Assuming you have soapUI project with one test suite named TestSuite - Groovy. This test suite have test case TC - Examples and it have test steps: Context Wrapper - items and CW - properties.

In test step Context Wrapper - items which is Groovy test step type you define wrapper like this:

import stoolz.soapui.wrappers.RunContextWrapper
def cw = new RunContextWrapper(context)

cw would be run context wrapper while context is build in soapUI's run context. Then this all is true:

cw.testCase == context.testCase
cw.testSuite == context.testCase.testSuite
cw.project == context.testCase.testSuite.project
cw."CW - properties" == context.testCase.getTestStepByName("CW - properties")
cw."General Test" == ModelSupport.getModelItemProject(context.getModelItem()).getTestSuiteByName("General Test"))

In last line we are assuming that project have test suite General Test, which do not contain running test case.
Adding properties on run context is in same manner:

context.setProperty("test property", "test property value")
cw."test property" == context.getProperty("test property")

context.setProperty("test property", "XXX")
cw."test property" = "YYY"
cw."test property"== context.getProperty("test property")

cw."test property" = "YYY"
cw."test property" ==context.getProperty("test property")

This means that with wrapper you can set/read run context property. In same manner you can access other test steps in owner test case or other test suites. Only thing that needs to have in mind is order of resolution. When you do:

cw.myThing

context wrapper first checks for run context properties, then for test steps and last for test suite names. Than means if you have property named myProperty and test step with same name line above will always return property value.

Send mail script

At your disposal is send mail script:

import stoolz.utils.SendMail
def mail = new SendMail()
mail.initGMail("my gmail account" , "my secret password")
mail.send( "to address", "subject", "mail body" )

In previous example built in gmail configuration is used, but you can configure it to use your own mail server with:

mail.configure(mailHost, mailPort, fromAddress, user, password, ssl, enableStartTLS)

for properties ssl and enableStartTLS correct values can be true/false or on/off. For others you'll probably need to check you mail client configuration or/and talk with local admin.
There is two ways to send emails, without attachments ( look above ) or with them:

mail.send(toAddress, subject, mailMessage, attachmentDir, filePattern)

where file pattern is something like *.zip.

Installing

To use stoolz you need to add it to {soapui.home}/ext folder, while dependencies need to be in lib folder ( {soapui.home}/../lib ). Dependencies ( see build.gradle file for versions ), which goes in lib folder are:

ant-javamail
ant
antlr
ant-launcher

You can download stoolz here.

Issues, suggestions etc...

If you thinks this can help you in your daily work, have issues or have any suggestion you can send me email or open issue here.

Asserting JSON in soapUI

noreply@blogger.com (ddd) — Wed, 29 Aug 2012 12:49:00 +0000

-------------------------------------------------------------------------------------------------------------
Book Groovy for soapUI users will be available soon. More information on this page.
-------------------------------------------------------------------------------------------------------------

JSON stands for JavaScript Object Notation and it is lightweight data presentation format. It should be easy understandable for humans. Basically if you do not want and do not need to go in details it is same thing as XML just different packaging. As you already know or guessed when soapUI was created SOAP services were in team focus.

So, in soapUI you have good support for testing SOAP services and manipulating XML. What about REST and JSON?

JSON is soapUI

Good news is that there is no much difference when working with XML and JSON in soapUI. soapUI have number of features that uses XPath to manipulate XML. Of course, you can not use XPath expressions on JSON. Or maybe you can? In soapUI you can thanks to the fact that soapUI converts JSON to XML. That way what ever you did to assert, validate, check on etc..on XML response same thing you can do with JSON response. Only difference is that instead using Response property you have to use ResponseAsXml property. ResponseAsXml is soapUI's attempt to convert JSON to XML and all tools that you already used for XML use on JSON.

And this is how converted XML looks likes:

and original JSON like this:

Nice and peachy but...

There is always one but. Problem with converting JSON to XML is that XML forces some rules that JSON do not have:

Names can contain letters, numbers, and other characters
Names cannot start with a number or punctuation character
Names cannot start with the letters xml (or XML, or Xml, etc)
Names cannot contain spaces

Here you have an issue in soapUI, since soapUI can not convert JSON to XML if any of those rules will be broken. For example look at Twitters daily trends JSON response:

{
"trends": {
"2012-08-29 08:20": [
{
"events": null,
"name": "Bizim İçin Saldır Fenerbahçe",
"query": "\"Bizim İçin Saldır Fenerbahçe\"",
"promoted_content": null
},
{
"events": null,
"name": "#RemajaIndonesiaSeptemberWish",
"query": "#RemajaIndonesiaSeptemberWish",
"promoted_content": null
},
{
"events": null,
"name": "Most Share-Worthy Video",
"query": "\"Most Share-Worthy Video\"",
"promoted_content": null

As you can notice "2012-08-29 08:20" should be node value if converted to XML but that breaks XML naming rules. So you are stuck here since there is no XML and you need to do asserting.

Asserting JSON

Problem is soapUI cannot convert JSON to XML because it will broke XML naming rules. You can not use XPath and XQuery assertions because of that. You can use Contains and Not Contains assertions but they have very limited usage. What to do?

You should use your favorite assertion Script Assertion with Groovy flavor. It is easy and fun, look:

import groovy.json.JsonSlurper

def response = messageExchange.response.responseContent
def slurper = new JsonSlurper()
def json = slurper.parseText response

Script above get response content as String and pass it to JsonSlurper which parse this string and produce one big HashMap. Now working with HashMap is very easy in Groovy.

In this example ( Twitter Daily Trends ) JSON response have trends for number of dates, so if I want check if it contains trends for some particular date and time:

assert json.trends.'2012-08-29 08:20' != null

Notice that I had to put date under quotes since date contains white space, but trends are good. And now I want to be sure that I have eight trends for that date and time:

assert json.trends.'2012-08-29 08:20'.size == 8

and 7th element name is Toby:

assert json.trends.'2012-08-29 08:20'[7].name == "Toby"

and so on...Whole script can look like this:

import groovy.json.JsonSlurper

def response = messageExchange.response.responseContent
def slurper = new JsonSlurper()
def json = slurper.parseText response

assert json.trends.'2012-08-29 08:20' != null
assert json.trends.'2012-08-29 08:20'.size == 8
assert json.trends.'2012-08-29 08:20'[7].name == "Toby"

Notice that is you have several assertions one by one in Script Assertion like on example above first assertion that fails will stop executing script, which means assertions under it ( in script ) will not be executed.

That is it..have fun...

Modularization, Action and Keyword Testing in soapUI

noreply@blogger.com (ddd) — Mon, 26 Mar 2012 18:05:00 +0000

New post published on Smart Bear blog:
http://blog.smartbear.com/post/12-03-13/modularization-action-and-keyword-testing-in-soapui/

soapUI 4.5 Beta 1 Overview

noreply@blogger.com (ddd) — Thu, 01 Mar 2012 11:23:00 +0000

This week we got chance to try new soapUI. It is soapUI 4.5.0 Beta 1, so it is still rough on some edges but shape is nicely visible. Of all new stuff that soapUI 4.5 bring us these are major:

Environments
Test Debugging
Message Content Assertion
Assertion Test Step

Unfortunately all are in Pro version, so either you buy soapUI or use trial.

Environments

This feature bring us a possibility to create different testing environments. This makes me easier to update all properties ( usernames, passwords, etc ) when switching to test on different server. In Project panel you can find Environment tab and add, remove or clone environments.

soapUI Environment

As you can see environment is defined with:

one SOAP endpoint - this is optional. Here you define it and while environment is active only in this panel you can change it.
one REST endpoint - same as above.
custom properties - optional. This is actually project properties. Environment custom properties override project properties. Names and number of properties is same for all environments just values can be different.
jdbc connections - here you override configurations set in JDBC tab.

Changing/setting environment is done on test suite or test case level:

Selecting Environment

As you can see there is one hidden environment, it is default one. This one is created when you create project and you can look at it as baseline environment.

Test Debugging

Finally not only developers can do debugging. Idea behind this one was to allow tester to see how test case behaves. Excellent to see if your test is buggy or web service you are testing, since now you can be sure from where those weird values are coming from.

You can find test debugging on test case level:

Test Case Debugging

Here you can see:

test step list on left. Here you can add ordinary and conditional breakpoint. For conditional breakpoint you need to write groovy script in which you check for condition and based on it return true or false. Test case execution will stop on ordinary break point or on conditional if condition script returns true. That small green arrow shows which test step is about to be executed.
on right you can see listed project properties, test suite properties, etc...Here you can inspect them. Of course you can have lot of test step and this can be crowded, so you can filter only those you need. And you can keep them collapsed since soapUI will notify you if some property change its value. Notice there is Property Expansion table. Now you can see what property expansion is executed and what is its current value.
at bottom right you can see property value you selected in upper table. This is for those properties which have lot of text as value, like response.

Message Content Assertion

This would be like aggregated version on XPath assertion:

Picture says all. Based on one request you select elements you want to compare and select operator ( <, >, =, etc ), set expected value and that is it. This assertion based on your selection generates XPaths which are saved with expected values. Next time request is run this assertion looking for nodes based on saved XPaths and if they exists compare theirs values with expected values. This means even if response XML changes response gets validated. You can reconfigure it. In that case you are asked do you want to keep old XPaths and add new ones or start from begging.

Assertion Test Step

This would be assertions aggregation. In this test step you add assertions which targets other test steps, test case properties, test suite properties or project properties. Than you can group those assertions and apply AND or OR logic:

Here you can notice that we also got new assertion logic. Now you can assert property value, not just Response or Request. This is also visible in new Add Assertion Dialog:

Assertions are also grouped in categories and I have Recently Used.

Conclusion

I think we got nice set of features that can help in every day work. There other improvements like new licensing system ( floating licenses ), improved wss and saml support, etc..but these four stand out for now.

Security Scans in soapUI

noreply@blogger.com (ddd) — Thu, 22 Dec 2011 20:34:00 +0000

Here I show you how to use soapUI to hack a Hacme Casino. Read and enjoy...Here is a link on http://www.softwarequalityconnection.com/2011/12/how-to-check-your-web-app-for-security-vulnerabilities/

XML Parsing in soapUI

noreply@blogger.com (ddd) — Mon, 07 Nov 2011 21:45:00 +0000

Introduction

Since soapUI allows users to add Groovy scripts in large number of places ( property expansions, setup /teardown scripts, listeners, test step, etc... ) users can use any technology to reach to the goal. Lets look at those which can make our life easier when it comes to XML parsing.

soapUI XML Support

Old way would be soapUI way or using GroovyUtils from soapUI. Its goal is to simplify scripting and it can be instantiate from any Groovy script in soapUI, with:

def groovyUtils = new com.eviware.soapui.support.GroovyUtils( context )

where context is available in any Groovy script in soapUI. Lets look at GroovyUtils:

GroovyUtils Methods
`expand(property)`	returns value of property, if there are property expansions they are expanded.
`extractErrorLineNumber(error)`	returns line number where error occurred
getProjectPath()	returns path to project file
getXml(node)	returns xml as a string from passed node
`getXmlHolder(xmlPropertyOrString)`	returns XmlHolder as a result of parsing passed Xml string
`registerJdbcDriver(driver)`	register JDBC driver for use in Groovy script
`setPropertyValue(testStep, property, value)`	sets a value for given test step property

This time getXmlHolder is one that does what we need. Pars a given string as XML and returns object which we can use to manipulate with it.

XmlHolder Methods
`declareNamespace(prefix, uri)`	declare namespace prefix and URI
`getDomNode(xpath)`	returns a DOM node pointed by XPath expression
`getDomNodes(xpath)`	returns an array of DOM nodes pointed by XPath expression
`getNamespaces()`	returns a Map of namespaces
`getNodeValue(xpath)`	returns a value of node specified by XPath expression
`getNodeValues(xpath)`	returns an array of values specified by XPath expression
`getPrettyXml()`	returns a formatted XML
`getXml()`	returns a XML
`getXmlObject()`	returns a XmlBean Object
removeDomNodes(xpath)	removes a nodes specified by XPath expression
`setNodeValue(xpath, value)`	set a node value
`updateProperty()`	if a XmlHolder is created from test step property this updates that property
`updateProperty(prettyPrint)`	if a XmlHolder is created from test step property this updates that property with well formatted XML

Few Examples

Assume you have response:

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:sim="http://www.example.org/SimpleSocialSOA/">
<soapenv:Header/>
<soapenv:Body>
<sim:LoginResponse>
<id>4456643453</id>
</sim:LoginResponse>
</soapenv:Body>
</soapenv:Envelope>

For this examples I added a Properties Test Step with property response.

1. Parsing XML

According to that to get id from response you can do:

def groovyUtils = new com.eviware.soapui.support.GroovyUtils( context )
def holder = groovyUtils.getXmlHolder("Properties#response")
log.info holder.getNodeValue("//id")
log.info holder['//id']

notice two ways to get node value with getNodeValue method and with [] operator. Difference is that getNodeValue will return first value that can be found with set XPath, while [] operator returns a array of values.
If you assume that response is like:

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:sim="http://www.example.org/SimpleSocialSOA/">
<soapenv:Header/>
<soapenv:Body>
<sim:LoginResponse>
<id>4456643453</id>
<id>4456643452</id>
<id>4456643451</id>
<id>4456643450</id>
</sim:LoginResponse>
</soapenv:Body>
</soapenv:Envelope>

Than this script:

def groovyUtils = new com.eviware.soapui.support.GroovyUtils( context )
def holder = groovyUtils.getXmlHolder("Properties#response")
log.info holder.getNodeValue("//id")
for( node in holder['//id'] )
log.info node

will produce result like this:

2. Updating XML

Response as above and we do:

def groovyUtils = new com.eviware.soapui.support.GroovyUtils( context )
def holder = groovyUtils.getXmlHolder("Properties#response")
holder.setNodeValue("//id", "aaaaa")
for( node in holder['//id'] )
log.info node
def holder2 = groovyUtils.getXmlHolder("Properties#response")
holder2.getNodeValue("//id")
for( node in holder2['//id'] )
log.info node

Result is:

from this we can learn:

if there are several nodes as result of XPath expression only first's node value will be changed with setNodeValue
setting node value is not enough to update property value, we forgot to use updateProperty method

Correct Groovy script would be:

def groovyUtils = new com.eviware.soapui.support.GroovyUtils( context )
def holder = groovyUtils.getXmlHolder("Properties#response")
holder.setNodeValue("//id", "aaaaa")
for( node in holder['//id'] )
log.info node
holder.updateProperty()
def holder2 = groovyUtils.getXmlHolder("Properties#response")
holder2.getNodeValue("//id")
for( node in holder2['//id'] )
log.info node

Instead of using:

holder.setNodeValue("//id", "aaaaa")

you can use also:

holder["//id"] = "aaaaa"

And if XmlNode is created from property as in example above use updateProperty method to apply your changes to property or use GroovyUtils.setPropertyValue method.

Groovy XML

There are three classes built in Groovy for processing XML: XMLParser, XMLSlurper and DOMCategory. Best practice is to use XMLSlurper in soapUI. Reason is that it have smallest memory footprint from all three. I would no go in depths for those, you can read here XML processing.
This for example:

import groovy.xml.StreamingMarkupBuilder
def response = context.testCase.testSteps['Properties'].properties['response'].value
def responseXml = new XmlSlurper().parseText(response)
responseXml.breadthFirst().each {
def v = it.toString()
if ( it.name() == 'id')
it.replaceBody("$v XX")
}

appends " XX" to values of all id nodes.

Generally it is easier to use GroovyUtils but if you are familiar or invest some time in XmlSlurper you can get better results and more flexible scripts.

soapUI & HTTP Authentications ( part two )

noreply@blogger.com (ddd) — Tue, 01 Nov 2011 08:28:00 +0000

Discover how to use Digest HTTP Authentication. The second part is published on SmartBear blog.

soapUI & HTTP Authentications ( part one )

noreply@blogger.com (ddd) — Sun, 02 Oct 2011 14:44:00 +0000

It is a method for client ( like web browser ) to provide user name and password to server when making a request. It is specified in RFC 1945 [2] (Hypertext Transfer Protocol – HTTP/1.0). Additional information can be found in RFC 2616 (Hypertext Transfer Protocol – HTTP/1.1) and RFC 2617 (HTTP Authentication: Basic and Digest Access Authentication).

How does it work?

When client request a content from server if it authentication required server informs client that authentication is required and authentication type. Than client repeats request with required authentication type. This would be general description.

In case of basic HTTP authentication it would be like this:

1. Client request some content from browser:

GET /user/list.html HTTP/1.1
Host: localhost

2. Server returns HTTP error 401 which means that authentication is required, with authentication type:

HTTP/1.1 401 Authorization Required
Server: HTTPd/1.0
Date: Sat, 27 Nov 2004 10:18:15 GMT
WWW-Authenticate: Basic realm="Secure Area"
Content-Type: text/html
Content-Length: 311

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
 "http://www.w3.org/TR/1999/REC-html401-19991224/loose.dtd">
<HTML>
  <HEAD>
    <TITLE>Error</TITLE>
    <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">
  </HEAD>
  <BODY><H1>401 Unauthorized.</H1></BODY>
</HTML>

Where in response header this:

WWW-Authenticate: Basic realm="Secure Area"

is HTTP header which caries this information.

3. Client ask user for user name and password, encrypts them and send to server :

GET /user/list.html HTTP/1.1
Host: localhost
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

Basically algorithm is like this:

Client takes values for username and password and creates string username + ":" + password.
Than that string is encoded with base 64.
In HTTP header of new request is added header Authentication with value "Basic <encoded64base( username:password )>".

So, this :

Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

is information required by server. This tells server that this is basic HTTP authentication. Server authenticate user from:

QWxhZGRpbjpvcGVuIHNlc2FtZQ==

That is a string "username:password" encrypted with base 64. Server just execute reverse operations: decode and than splits string to get username and password provided by user.

How this works in soapUI?

In soapUI this works out of box. First you need to enable preemptive authentication:

Now you are able to specify username password in several places:
1. On request level:

2. On test case level:

These values will be applied to all requests in test case.
3. On interface level:

These values will be applied when ever this endpoint is used in request based on mode:

OVERRIDE - use this values and override if same HTTP header already exists, do not change username/password properties on request
COMPLEMENT - add this values to existing headers
COPY - copy these values to username/password properties on request

soapUI MockService and Basic HTTP Authentication

Unfortunately basic HTTP authentication does not work out of box in soapUI, so some effort is needed for you to have in your mock service. First you need to be familiar how to use scripting possibilities in mock service ( soapUI - Developing Web Service with Groovy ).
We'll start with this script:

for( header in mockRequest.requestHeaders )
   log.info "${header.key} : ${header.value[0]}"

If this script is placed in OnRequest Script in MockService panel, when request is sent on mock service you should see something like this:

Item mockRequest is available in OnRequest Script and it represent request received. Than this: mockRequest.requestHeaders is a map of all HTTP headers in request and their values. Notice that one HTTP header can have multiple values. In this case we are interested in first one that comes in requests header. Result could be verified if you look raw request in Request Panel:

O.k, plan is to check if request have Authorization header and correct values for username and password. If any of these conditions are not met client needs to be notified:

 def response = new com.eviware.soapui.impl.wsdl.mock.WsdlMockResult( mockRequest )
 mockRequest.httpResponse.status = 401
 mockRequest.httpResponse.writer << "ERROR"
 return response

In case that Authorization header exists username and password needs to be verified:

def value = auth[0]
      if ( value.startsWith("Basic ")) {
       value = value.substring( 6 )
         def up = new String(value.decodeBase64()).split(":")
         def user = up[0]
         def pass = up[1]
         if( !(user == "robert" && pass == "test") ) {
        return errorResult.call()
         }
      }

Here Authorization header value is taken, checked if it is Basic authorization. Rest of value is decoded and split so username and password can be extracted. Than those values are compared with set username and password. So, whole script looks like this:

def errorResult = {
 def response = new com.eviware.soapui.impl.wsdl.mock.WsdlMockResult( mockRequest )
 mockRequest.httpResponse.status = 401
 mockRequest.httpResponse.writer << "ERROR"
 return response
}

def auth = mockRequest.requestHeaders["Authorization"] 
if ( auth  ) {
      def value = auth[0]
      if ( value.startsWith("Basic ")) {
       value = value.substring( 6 )
       def up = new String(value.decodeBase64()).split(":")
       def user = up[0]
       def pass = up[1]
       log.info "$user $pass"
       if( !(user == "robert" && pass == "test") ) {
        return errorResult.call()
       }
      } else {
       return errorResult.call()
      }  
   } else {
    return errorResult.call()
   }

Notice that errorResponse is closure which creates error response and it will be called if no Authorization header or it is not basic authorization or user name or password do not matches required values. In this script username/password pair is set to be robert/test.

That is it about basic HTTP authentication in soapUI....next time digest authentication...

soapUI: Working with properties

noreply@blogger.com (ddd) — Tue, 21 Jun 2011 20:10:00 +0000

-------------------------------------------------------------------------------------------------------------
Book Groovy for soapUI users will be available soon. More information on this page.
-------------------------------------------------------------------------------------------------------------

Almost every item in soapUI have a set of a properties that describes its context. It is a string to string map. That means each property have name and value which are strings.

Overview

Basically, they are used to describe context of elements in your test. That means they are one of crucial mechanics in soapUI. When ever you select any test element in project tree you can inspect its property values in down left corner. As you can notice each element have default properties which are set by soapUI.

properties

In this example you can see properties in navigator, too. Showing properties in navigator is turned on by button in navigator's top left corner.
Describing and manipulating tests are not only purpose of properties. They can be used to store, keep and transfer values from one test item to another. Simple said if I want any value to be kept and than reused somewhere else I'll use properties. Obvious example for this is need to use values from response in next request. Like, user id which is obtained from login request. Most of properties are available for writing and reading, but some are just for reading. Those read only are important for projects consistency, so they can be changed as regular properties.

Inspecting Properties

To see what are properties on some item there are two ways: in UI by selecting item in navigator tree and inspecting table in down left corner or by soapUI API. Doing it with Java means invoking getProperties() method on item. In Groovy it can be done same way or Groovy way:

context.currentStep.properties.each { key, value ->

log.info "${key} : ${value.value}"

}

And result would be:

Sun Jun 19 17:48:18 CEST 2011:INFO:result : {result=com.eviware.soapui.model.support.DefaultTestStepProperty@440d13, script=com.eviware.soapui.model.support.TestStepBeanProperty@1b69500}
Sun Jun 19 17:48:18 CEST 2011:INFO:script : context.currentStep.properties.each { key, value ->
log.info "${key} : ${value.value}"
}

Which can be checked if you look in test properties table for groovy script test step. It have two default properties: script and result. Second one is read only, and holds result of last execution.

Accessing Properties

As you can see some properties can be set by user and some are set as execution's result by some operation which is usually test step. Those properties which are set as execution's result are most valuable ones so I need to be able to use those values automatically all over my test. That means in it should be available across whole project. There are two ways to do that: property transfer test step and property expansion.

Property Transfer Test Step

This is easy one. All one should do here is to create transfer, select source and its property, than destination and its property. Since here is common for result to be a XML you have a panel to add a XPath statement so the right node/value can be extracted from it. In soapUI Pro you have XPath selector to make your life easier.

property transfer

Property Expansion

Property Transfer test step is there to make life easier and it is enough if you need to transfer value or part of its value ( XML node for example ) to another property. But if you need to use some properties in mock service, or have chain of test steps and need to propagate property values from previous one to next one it is cumbersome to add property transfer in between each two test steps. For cases like these it is more appropriate to use property expansion.
Syntax for property expansion looks like this:

${#<scope>#<property name>} -- property expansion for defined scope
${<test step name>#<property name>} -- test step property
${=<groovy expression>} -- dynamic property

In soapUI when talking about property transfer you have these scopes:

Project
TestSuite
TestCase
Security , these are properties defined for security tests which are available from soapUI 4.0
MockService
Global , these are global properties
System , system properties
Env , environment properties

Properties for project, test suite, test case, security and mock service scopes are only available if you call property expansion in that scope, notice that there is a hierarchy for those scopes:

property scopes

This means that you can call property expansion to get project level property any where in project, but if you want to get test case property you can call it when you are on test case level or on its children level ( security test, test steps, load test ).

So, if you have property jira domain on project level you can access it anywhere in project with:

${#Project#jira domain}

but if you have domain domain password property for test case with:

${#TestCase#domain password}

you can access it only in test case where this property exists and its children.
Last three scopes are available trough whole soapUI, where Global represent properties defined for whole soapUI. You can set them in soapUI preferences, or load them when starting soapUI by setting value for soapui.property:

-Dsoapui.property=<path to file>

System properties could be seen from Help menu. And Env are environment properties like MAVEN_HOME:

${#System#user.home}
${#Env#MAVEN_HOME}

In property transfer test step you can specify a XPath expression to extract a portion of property value if it is a XML. To do that with property expansion you need to add XPath expression and the end of property expansion like:

${IsValidEmail#Request#declare namespace res=\'http://www.example.org\'; //res:userName[1]}

Where IsValidEmail is a soap request test step name. In last example test step's IsValidEmail property Request (which all request test steps have) is taken as source. Also, since it have a XML value XPath expression is evaluated on it, so I could get just a value of node to transfer to my next request, for example. So, that would be like this:

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:sim="http://www.example.org/SimpleSocialSOA/">
<soapenv:Header/>
<soapenv:Body>
<sim:FindUser>
<name>${IsValidEmail#Request#declare namespace res=\'http://www.example.org\'; //res:userName[1]}</name>
</sim:FindUser>
</soapenv:Body>
</soapenv:Envelope>

Last, and maybe most interesting way to execute property expansion is dynamic ones. You could look on them like inserting a portion of Groovy code where ever property expansion could fit. So, if your request is needed to pass unique id in request you could use it like this:

${=Math.random() * 10000}

or you want to get a number of test suites in your project:

${=project.testSuites.size()}

or if you want to put result of external command to your property:

${=new Scanner(\"ls -al\".execute().inputStream).useDelimiter(\"A\").next()}

which will return list of files from current working directory in one line if you are on linux. But, what is powerful here is that this is execution a run time added execute() on a String, this is done by Groovy. Than I pick up result and with a little help of java.util.Scanner turn into String. This means that I can make my set of classes, Java or Groovy, package it all in jar file and if put in ext folder they will be added to class path. So, I can use them to execute my functions... So, with this I'm not bound to use just Java/Groovy or soapUI classes but can easily add mine. How hard is that? I'll give you example. Let say my Java class looks like this:

public class HelloJava {

public static String hello(String name) {
return "Hello " + name + ". How are you?";
}

}

or in Groovy:

public class HelloGroovy {

def hello = { name ->

"Hello $name. How are you?"

}

Than save it java in HelloJava.java and Groovy in HelloGroovy.groovy, and compile it:

javac HelloJava.java

Groovy:

groovyc GroovyJava.groovy

than pack it:

jar cf javahello.jar H*.class

and Groovy:

jar cf groovyhello.jar G*.class

Notice that groovyc produced two class files since I have closure. Than copy it in {soapui.home}/bin/ext and it is ready to use:

${=HelloJava.hello("Robert")}

and:

${=new HelloGroovy().hello("Robert")}

Simple....Now all what is left to let your imagination work...

soapUI - Developing Web Service with Groovy

noreply@blogger.com (ddd) — Mon, 06 Jun 2011 19:49:00 +0000

This article is moved from my Google site.

soapUI, well known, tool for functional and load testing web services, have integrated Groovy in it. It is usually used for creating complex tests, or doing stuff that are specific for test or not supported by tool itself.

MockService really cool thing...

This soapUI feature enables mocking a web service based on its definition. So, I can write a test for web service while it is in development just based on wsdl, if wsdl changes soapUI have a solution for that, too. That is for another time. Most important thing now is how can I test my tests before they are used on real thing?

Creating a MockService

Doing this in soapUI is quite easy, with just click on a button it creates you a basic setup for MockService. Just right click on interface and choose “Generate MockService”. Now I have something to work with:

Things of my interest are:

Properties tab - for properties, look at them as a global properties for mock service.

Start/Stop Script tab - these two Groovy scipts are executed when mock is started/stoped.

OnRequest Script - this one Groovy script executes when request is received

AfterRequest Script - and this Groovy script when response is dispatched

If you double click on any of those operation you’ll get an operation editor. Here you can choose several ways to determine a response. They are all pretty powerful features but I’m going for script dispatch method.

Scripting a dispatching...

If you choose script as dispatch method you’ll see a script editor and that you have several variables for your disposal:

log - for logging/debugging since println is useless here.
context - mock runner context
requestContext - mock request context
mockRequest - request
mockOperation - operation

Use these based on what you need. Basically what you need is to get xml from request and to modify response according to request. One more thing script should return a string which is a name of response. And a list of response for that operation is in upper tab.
So, I set two responses named Response and Error. I’ll be using a Response content to create a real response and Error content when I want send error. Actually I’ll not modify Error response at all, I’ll use as I defined it. So, script looks like this:

import groovy.util.XmlSlurper

import groovy.xml.StreamingMarkupBuilder



request = new XmlSlurper().parseText(mockRequest.requestContent).declareNamespace(soapenv:"http://schemas.xmlsoap.org/soap/envelope/", gro:"http://www.example.org/GroovyWSDL/")

response = new XmlSlurper().parseText(mockOperation.getMockResponseByName("Response").responseContent).declareNamespace(soapenv:"http://schemas.xmlsoap.org/soap/envelope/", gro:"http://www.example.org/GroovyWSDL/")



if ( request.'soapenv:Body'.'gro:getFriendRequest'.name == "Robert" ) {

 response.'soapenv:Body'.'gro:getFriendResponse'.friend.with {

  firstName = "Robert"

  lastName = "Nice"

  birthday = "Some day"

 }

 

 mockOperation.getMockResponseByName("Response").responseContent = new StreamingMarkupBuilder().bindNode(response)

 "Response"

} else {

 "Error"

}

xml I expect to get is like:

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:gro="http://www.example.org/GroovyWSDL/">
<soapenv:Header/>
<soapenv:Body>
<gro:getFriendRequest>
<name>?</name>
</gro:getFriendRequest>
</soapenv:Body>
</soapenv:Envelope>

So, with :

mockRequest.requestContent

I’m getting an xml and user XmlSlurper to parse it and check for incoming values. Next, thing is to modify response. Since I have to possible response I’ll fetch one that keeps xml response template and modify it to my needs:

response.'soapenv:Body'.'gro:getFriendResponse'.friend.with {
firstName = "Robert"
lastName = "Nice"
birthday = "Some day"
}

Now, I have to update Response content and dispatch it:

mockOperation.getMockResponseByName("Response").responseContent = new StreamingMarkupBuilder().bindNode(response)
“Response”

This script checks if name is Robert and than it returns a response for that input, otherwise returns Error, which in this case in Unknown.

But this have one flaw, I’m changing a Response content so I’m changing my template, which is no good. So, I’ll add a property to mock service as default response holder. All I have to do is to go back to MockService panel, open a Properties tab and add one property which will contain a default xml. I named my property def_response and change this:

response = new XmlSlurper().parseText(context.mockService.properties.def_response.value).declareNamespace(soapenv:"http://schemas.xmlsoap.org/soap/envelope/", gro:"http://www.example.org/GroovyWSDL/")

Now, I’m using a template to create a response.

Moving outside soapUI...

Keeping everything in soapUI is nice, but I would like to create my logic a bit complicated and more modular. What I could do is to create script which could handle request xml and return a response xml. Something like this:

import groovy.util.XmlSlurper
import groovy.xml.StreamingMarkupBuilder

public class Dispatch {

def def_response = '''
<soapenv:Envelope xmlns:soapenv='http://schemas.xmlsoap.org/soap/envelope/'>
<soapenv:Header/>
<soapenv:Body>
<gro:getFriendResponse xmlns:gro='http://www.example.org/GroovyWSDL/'>
<friend>
<firstName>?</firstName>
<lastName>?</lastName>
<birthday>?</birthday>
</friend>
</gro:getFriendResponse>
</soapenv:Body>
</soapenv:Envelope>
'''

def error = '''
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:gro="http://www.example.org/GroovyWSDL/">
  <soapenv:Header/>
  <soapenv:Body>
     <gro:getFriendResponse>
        Unknown
     </gro:getFriendResponse>
  </soapenv:Body>
</soapenv:Envelope>
'''

String process( String input) {

def request = new XmlSlurper().parseText(input).declareNamespace(soapenv:"http://schemas.xmlsoap.org/soap/envelope/", gro:"http://www.example.org/GroovyWSDL/")
def response = new XmlSlurper().parseText(def_response).declareNamespace(soapenv:"http://schemas.xmlsoap.org/soap/envelope/", gro:"http://www.example.org/GroovyWSDL/")

if ( request.'soapenv:Body'.'gro:getFriendRequest'.name == "Robert" ) {
response.'soapenv:Body'.'gro:getFriendResponse'.friend.with {
firstName = "Robert"
lastName = "Nice"
birthday = "Some day"
}

new StreamingMarkupBuilder().bindNode(response)
} else {
error
}
}
}

and in soapUI to have:

mockOperation.getMockResponseByName("Response").responseContent = new Dispatch().process(mockRequest.requestContent)
"Response"

Which is much cleaner. To do this just create a script and put in {soapui.home}/bin.scripts or some other folder and in soapUI project properties set property “Script Library”. Basically Dispach script is a gateway to your business logic. Layer under it could do what ever you wish, you could create a whole web service this way. It will not be a best one, but it will be more that enough for creating a test cases and validation for real web service while it is developed, before it can be deployed on test servers.

soapUI: extending a tool - adding Groovy scripts library

noreply@blogger.com (ddd) — Sun, 05 Jun 2011 20:03:00 +0000

-------------------------------------------------------------------------------------------------------------

Book Groovy for soapUI users will be available soon. More information on this page.

-------------------------------------------------------------------------------------------------------------

soapUI as functional web service testing tool can do almost anything. If there is something that is missing with little help of Groovy scripts it can be done. So, with time you end with bunch groovy scripts. And when ever you want to use them you go trough your projects to look for them. And most of the time they are almost same. So, they could be reused.

soapUI extension mechanic

If you look at open source version you’ll find soapui-actions.xml file. There you first associate an alias, id, with action implementation class and than you group them in action groups. Each of these action groups are associated with some modelItem ( test step, test case ...) Since, already there are action groups associated with different modelItem best approach for start is to add new action to desired group. Basically, soapUI have action registry and there you add or merge actions.

Let say you installed soapUI at {soapui.home} than {soapui.home}/bin/actions is a place where you put a xml file which tells soapUI how to handle pop-up menus in navigator.
In, this example it is a test case :

<?xml version="1.0" encoding="UTF-8"?>
<tns:soapui-actions xmlns:tns="http://eviware.com/soapui/config">


<tns:action id="scriptLibrary" actionClass="com.soapuitools.action.ScriptLibrary"/>


<tns:actionGroup id="WsdlTestCaseActions">
<tns:actionMapping actionId="scriptLibrary"/>
</tns:actionGroup>

</tns:soapui-actions>

So, I said here that my class that performs an action is com.soapuitools.action.ScriptLibrary and add it to test case action group which name is WsdlTestCaseActions. This file goes to {soapui.home}/bin/actions. I named it my-actions.xml. One notice here this xml have to ends with -actions.xml to be picked up by soapUI.

Implementation

Ok, now you need to implement ScriptLibrary class. To do that you just need to implement AbstractSoapUIAction. And that means, this:

import com.eviware.soapui.model.ModelItem
import com.eviware.soapui.support.action.support.AbstractSoapUIAction

public class ScriptLibrary extends AbstractSoapUIAction
{
public ScriptLibrary()
{
super( "soapUI Tools-ScriptLib", "Script Lib" )
}

public void perform( ModelItem target, Object param )
{
// do something usefull here
}
}

I did this in Groovy here, if you do it in Java its same story. In my case it looks like this:

package com.soapuitools.action

import javax.swing.JDialog
import javax.swing.JFileChooser
import javax.swing.filechooser.FileFilter

import groovy.swing.SwingBuilder

import com.eviware.soapui.impl.wsdl.WsdlProject
import com.eviware.soapui.model.ModelItem
import com.eviware.soapui.support.UISupport
import com.eviware.soapui.support.action.support.AbstractSoapUIAction
import com.eviware.soapui.impl.wsdl.WsdlInterface
import com.eviware.soapui.impl.wsdl.testcase.WsdlTestCase
import com.eviware.soapui.impl.wsdl.teststeps.registry.GroovyScriptStepFactory

public class ScriptLibrary extends AbstractSoapUIAction {

WsdlTestCase testCase
def swing = new SwingBuilder()
String tsName
File templateFile
JDialog dialog

public ScriptLibrary() {
super( "soapUI Tools-ScriptLib", "Script Lib" )
}

public void perform( ModelItem modelItem, Object arg1 ) {

dialog = swing.dialog(modal:true) {
gridLayout(cols: 1, rows: 2)
label(text:"Enter test step name")
def tx = textField(columns:10)
button(action: action(name:"Choose File") {
def openDialog = swing.fileChooser(
currentDirectory: new File( System.getProperty("soapui.home",".") ),
dialogTitle:"Choose a template file",
id:"openDialog",
fileFilter: [getDescription: {-> "*.gtp"}, accept:{file-> file ==~ /.*?\.gtp/ || file.isDirectory() }] as FileFilter) {}
if(openDialog.showOpenDialog() != JFileChooser.APPROVE_OPTION) return //user cancelled
templateFile = openDialog.selectedFile
})
button(action:action(name:"Ok") {
tsName = tx.text
dialog.visible=false
})
}
dialog.pack()
dialog.show()

if (modelItem instanceof WsdlTestCase )
testCase = modelItem as WsdlTestCase

if ( tsName?.trim() != "" && templateFile?.exists()) {
def gs = testCase.addTestStep( GroovyScriptStepFactory.GROOVY_TYPE, tsName )
def script = ""
templateFile.eachLine { line -> script+='\n' + line}
gs.properties["script"].value = script
}
}
}

So, I just created templates directory in {soapui.home}/bin directory and I put my Groovy script templates in it with extension gtp. Now, all I need is to compile ScriptLibrary, pack it in jar and put that jar in {soapui.home}/bin/ext folder. Next time I started soapUI I got new menu item in test case pop-up. UI is lame but it does the job. You can modify it foryour needs.

core and pro

There is one difference regarding soapUI core version ( free one ) and soapUI Pro, second one support actions in Groovy scrips. That means you do not need to compile it and pack it in jar file. Even more you do not need to restart soapUI Pro to pick up the changes in your action script. So, to use example above just remove package statement in script and put it in {soapui.home}/bin/scripts or in directory where you pointed soapUI Pro ( check global settings, look for script library settings ). Also, my-actions.xml needs to be modified too:

<?xml version="1.0" encoding="UTF-8"?>
<tns:soapui-actions xmlns:tns="http://eviware.com/soapui/config">

<tns:action id="GroovyScriptAction" actionClass="com.eviware.soapui.support.scripting.actions.SoapUIScriptAction"/>

<tns:actionGroup id="WsdlTestCaseActions">
<tns:actionMapping actionId="GroovyScriptAction" name="Add GTP" description="Add groovy test step from template"
param="ScriptLibrary"/>
</tns:actionGroup>

</tns:soapui-actions>

Difference here is that you map your acction to SoapUIScriptAction and you pass to it your Groovy script. Simple...

Change Testing: Groovy & Maven

noreply@blogger.com (ddd) — Sun, 05 Jun 2011 19:34:00 +0000

This article is moved from: my Google site.

Using unit testing usually becomes burden for developers and very often misleads. It is like testing bricks used to build house. They all could be perfect but still house could be lousy. What usually is problem with unit testing is actually hiding an errors in application design. Also, application design and its components design due all the rules like coupling, cohesion, modularity etc makes testing harder. For example take all those private methods and classes, they are so well hidden that you can not test them or you need to invest too much time to do it. Than if they are changed your tests needs to be changed to test properly functionality they are providing, again very often design forgets on tests.
Using Groovy for testing make testing much more easy and even brings some fun. Groovy have less restricted, simpler syntax. The one thing many people do not like is Groovy modifiers. And that is everything is accessible in Groovy, no more private and protected methods and properties. Well, true is they are there, but what interest me is that I can avoid access modifiers for my tests.
My goal is unit testing, that means to test units, bricks, that will allow me to build my system. And when I put my brick in some wall I need free access to it so I can test it. Also, from a point of Java developer it looks almost like Java, and makes you to change a way of thinking in more open minded way..

GMaven.....

GMaven is a maven 2 plugin that help you uses a groovy in your projects. So, basically I want to be able to write unit tests in Groovy and I want maven to use those tests. So, basically you need gmaven to project’s pom file:
...

<plugin>

<groupId>org.codehaus.gmaven</groupId>

<artifactId>gmaven-plugin</artifactId>

<goals>

<goal>generateTestStubs</goal>

<goal>testCompile</goal>

</goals>

</execution>

</executions>

</plugin>
...
and than add this:
...
<dependency>

<groupId>org.codehaus.groovy</groupId>

<artifactId>groovy</artifactId>

<version>1.8.0-beta-1</version>

</dependency>

<dependency>

<groupId>org.codehaus.groovy.maven.runtime</groupId>

<artifactId>gmaven-runtime-1.0</artifactId>

<version>1.0</version>

<scope>test</scope>

</dependency>

<dependency>

<groupId>junit</groupId>

<artifactId>junit</artifactId>

<version>4.8.1</version>

<scope>test</scope>

</dependency>

...

Now when you do:

mvn clean test

It will not only run java unit tests but also unit tests done in groovy. Now all is needed is to write some tests.

Groovy & JUnit

   As you can notice in pom file JUnit dependency is added. It is not necessary unless you want to run JUnit tests. So, how does it look :

import org.junit.After
import org.junit.Before
import org.junit.Test

class CustomerLookup2Test {

@Before
void setUp() throws Exception {
  println "setup"
}

@After
void tearDown() throws Exception {
  println "teardown"
}

@Test
void testTests() {
println "Test junit"
}
}

   This is a simple example of JUnit test that test a class CustomerLookup2 which could be a Java or Groovy, it does not matter. You can use all JUnit feature like in Java. There is nothing much to say about this its like in Java. But this is expected.

GroovyTestCase

Groovy brings on stage GrooovyTestCase which makes testing more easier. You got simpler syntax, new assertions :

assertArrayEquals(Object[] expected, Object[] value)
assertLength(int length, char[] array)
assertLength(int length, int[] array)
assertLength(int length, Object[] array)
assertContains(char expected, char[] array)
assertContains(int expected, int[] array)
assertToString(Object value, String expected)
assertInspect(Object value, String expected)
assertScript(final String script) // assert that a script runs without exceptions
shouldFail(Closure code) // assert that an exception was thrown in that closure
shouldFail(Class clazz, Closure code) // the same but for a class

Assuming you are testing this class:

package com.blogstar.custormer;

import java.lang.System;

public class CustomerLookup {

private String user;
private String pass;

public CustomerLookup(String user, String pass) {
this.user = user;
this.pass = pass;
}

public Customer lookForCustomerWithId(long id) {
createConnection();
return queryForUserWithId(id);
}

private Customer queryForUserWithId(long id) {
System.out.println("Fetching customer");
return new Customer();
}

private void createConnection() {
System.out.println("Creating connection! user = " + user + " and pass = " + pass);
}
}

So for this test class could look like this:

import groovy.util.GroovyTestCase
import com.blogstar.custormer.CustomerLookup

class CustomerLookupTest extends GroovyTestCase {

CustomerLookup customerLookup
void setUp() {
customerLookup = new CustomerLookup("robert", "blogstar")
}

void testQueryForUserWithId() {
customerLookup.lookForCustomerWithId(345)
}

void testCreateConnection() {
customerLookup.createConnection()
}

void testingSomeMethod() {
println "Here we are testing some method"
}

void tearDown() {
println "tearDown"
}
}

Basically Groovy unit test is something like this:

import groovy.util.GroovyTestCase

class BasicTest extends GroovyTestCase {

void testingSomeMethod() {
println "Here we are testing some method"
}
}

As you can in CustomerLookupTest I called a private methods to invoke them and test them. Here should be cleared that this is o.k if you test a private method without using others private methods, or to more clear on this it have to tested as a individual unit. If it is done differently than that it would mean you used it in manner not supposed to be used by design. In that case you are not testing it a properly, since you are using it in a way it will not be used, since design do not allow that.

Making a hierarchy of test...

   As parts of a code are put in some logical units, packages, in a same manner tests should be organized. Grouping unit tests that test some particular feature is done by test suites. Groovy also supports test suite. Actually GroovyTestSuite expands JUnit’s TestSuite. So, those who have expirience with JUnit TestSuite will have no problem creating one in Groovy:

import groovy.util.GroovyTestSuite
import junit.framework.Test

class RunAllTests extends GroovyTestSuite {
   static Test suite() {
       def allTests = new GroovyTestSuite()
       allTests.addTestSuite(allTests.compile("src/test/groovy/CustomerLookupTest.groovy"))
       allTests.addTestSuite(allTests.compile("src/test/groovy/CustomerLookup2Test.groovy"))

       return allTests
   }
}
And to run this by maven add this to pom file:
...
<properties>
   <test>RunAllTests</test>
</properties>
....
or start test with:

mvn clean test -Dtest=<test suite name>

   With this you can organize test in way your project’s design requires. You just need to point to test cases and compile them while putting in test suite. This looks a bit strange:

allTests.addTestSuite(allTests.compile("src/test/groovy/CustomerLookupTest.groovy"))

pointing to test case source and compiling it before adding to test suite but this could be used for something very useful.

Java keywords and their meaning

noreply@blogger.com (ddd) — Tue, 19 Jun 2007 12:05:00 +0000

Access Modifiers

private - Makes method or variable accessible only within its own class.
protected - Makes method or variable accessible to classes in same package or to subclasses of the class.
public - Makes class, method or variable accessible from any other class.

Class, Method and Variable Modifiers

abstract - Declares class that can not be instantiated, or method that have to be implemented by nonabstract subclass.
class - Indicates a class.
extends - Indicates a super class that subclass is extending.
final - Indicates that class is impossible to extend, method to override and variable to change value.
implements - Indicates a interface that the class is implementing.
interface - Indicates a interface.
native - Indicates that method is written in a platform dependent language.
new - Creates a new instance of a class by calling class's constructor.
static - Makes a method or a variable belong to a class as opposed to an instance.
strictfp - Used in front of a method or class to indicate that floating-point numbers will follow FP-strict rules in all expressions.
synchronized - Indicates that a method can be accessed only by one thread a time.
transient - Prevents fields from ever being serialized. Transient fields are always skipped when objects are serialized.
volatile - Indicates a variable may change out of sync because it is used in threads.

Flow Control

break - Exits a block of code in witch it is suitable.
case - Executes a block of code dependent of switch condition.
continue - Stops executing rest of loop's code( that goes after ) and starts new iteration.
default - Executes a block of code if non of switch statements are true.
do - Executes a block of code one time, than based on while statement determines will it be executed again.
else - Executes a block of code when if condition is not true.
for - Executes a conditional loop on block of a code.
if - Executes a logical test.
instanceof - Determines if a object is instance of a class, a superclass or a interface.
return - Returns from method not executing any code that follows.
switch - Indicates a variable that will be compared to case statements.
while - Executes a block of code in loop if given logical test is true.

Error Handling

catch - Declares a block of code that executes if exception occurs.
finally - Block of code that follows try block code and executes no matter how exception is handled.
throw - Used to pass an exception to method that called this method.
throws - Indicates a exception that can be thrown by a class or method.
try - Block of code that will be tried, but which may cause an exception.
assert - Evaluates a conditional expression to verify the programmer’s assumption.

Package Control

import - Declares what packages or class to import in code.
package - Define to which package code in file belongs to.

Variable Keywords

super - Reference variable referring to immediate parent class(super class).
this - Reference variable referring to the instance of current object.

Primitives

boolean - A value indicating true or false.
byte - An 8-bit signed integer.
char - An Unicode character(16-bit unsigned integer).
int - An 32-bit signed integer.
float - An 32-bit signed floating-point number.
long - An 64-bit signed integer.
double - An 64-bit signed floating-point number.

Void Return Type Keyword

void - Indicates that method does not have return type.

Unused Reserved Words

goto - bad practice.
const - use public final static.