06 August 2007 - 1.7.5 | home user-guide eclipse jbossws intellij netbeans maven 1.X/2.X PDF files forums bugs sourceforge

Home
Getting Started

- Functional Tests
- Load Tests
- Mocking
- Sample Project

User Guide
IDE/Tool Plugins
Search soapUI site
Project Documentation

- About soapUI
- Project Info
- Project Reports

## soapUI Sample Project

In order to make it easier for you to getting started with soapUI, we supply a sample soapUI Project file. This soapUI Projects illustrates some of the basic concepts of soapUI and can be used as a soapUI starting point; try out the project, run the included MockService and the included tests in order familiarize yourself with the soapUI interface, and then move on to the Getting Started tutorial.

Here are the main concepts that are illustrated in the soapUI Project.

## Web Service Mocking

Web Service mocking is very useful in projects were implementation of the Web service has not started or is not finished yet or where you for some other reasons can't access the Web Services live.

In soapUI you can create a Mock Service simply by choosing to add a Web Service Request to a Mock Service in order for the MockService to listen to it.

You can then choose how to Respond to the Request and choose how to Dispatch different responses.

Open the MockService, called SampleServiceSoapBinding MockService, by double clicking on it.

Browse through the different Interfaces in the MockService; login, logout, search and buy and see what we do at different requests. As you see all the requests are dispatched using scripts. This is by far the most common way of dispatching, but early on in a project you might just want to create a set of responses and dispatch them in sequence or at random.

You can start the MockService by pressing the MockService Start button.

Windows users who have used the installer also have an option for starting the sample MockService in the start menu under the soapUI installation.

## Web Service Inspection

Inspecting the Web Service can be done in two ways inspecting the Web Service and making Web Service requests.

### Inspect the WSDL

You can inspect a WSDL by Double Clicking the SampleServiceSoapBinding Interface Icon. You then get the Interface Viewer, a very useful tool for seeing what the WSDL contains and how it is structured.

This is a structured way of looking at your WSDL. Just browsing the XML of the WSDL is a very complicated task and is therefore seldom done resulting in lower WSDL understanding. The soapUI Interface Viewer is a great tool for solving this problem.

### Make Service Requests

Expand the login Interface and double click the login request. Login by using the username Login and the password Login123. You should now have gotten the response containing a sessionID 9575658833177431

Go ahead, try it!

No response? don't forget to start the MockService. We also need to copy the sessionID and use it to logout.

## Functional Tests

### Test Structure

Let's move on and look at how tests work in soapUI. We have created three different TestSuites all containing different TestCases. A TestCase is made up of several steps, called TestSteps. The structure of a soapUI project is like this;

- Project
- Interface
- TestSuites

- TestCases

- TestSteps
- LoadTests

- MockServices

As you can see there is also something called LoadTests, we can gather what they are, but we'll go into detail more what they actually do and how they actually work later.

### Functional Tests in detail

Now let's examine a Functional Test in a TestCase. Expand the TestSuite Sample Simple TestSuite and then double click the TestCase Simple Login and Logout w. Properties Steps. As you can see the case consists of 5 TestSteps.

You can also click the Description tab in order to see the in test documentation.

The step consists of three different types of TestSteps; One PropertyStep, Two Test Requests and Two PropertyTransfer Steps. This is what they do:

- PropertySteps: Stores Properties for later use. In our case it's the Username and Password required to login.
- Test Requests: The actual requests to the server. In this case login and logout.
- PropertyTransfers: A step used for moving properties between different steps. This might be from a Property Step to a request like the step Property Transfer: Move Username and Password does, or to move properties from a Test Request to another, like the step Property Transfer: Move sessionID does.

### Functional Tests continued

Double Click on each step and examine how they work. Double Click the TestSteps and you'll get the TestStep editor. You can for example see that the step Property Transfer: Move Username and Password moves does two transfers in two Properties.

- First it takes does the TransferUser Transfer. It takes the Property Username from the step Properties: Username and Password and moves it to the step Test Request: login.
- Then it takes does the TransferPass Transfer. It takes the Property Password from the said step Properties: Username and Password and also moves it to the step Test Request: login.

### Assertions

An important feature in Test are the assertions in Test Requests. Open the Test Step Test Request: logout.

In the TestStep we have four assertions, all asserting different things; That the response is a SOAP response, that it complies with the schema, that is isn't a SOAP fault and something called an XPATH match. The XPath Match validates that a certain element has the value expected.

### The Test Run

Now that we have examined the TestCase, let's run it! Press the Play Button and the Test will run and the Test Case progress bar should be full and green.

Does it turn red after only a step?

Don't forget to start the MockService.

Or... did you run the TestStep earlier?

Look at the response, maybe the response is that you already have a session?

We logged in earlier and aren't allowed to log in again, let's just go to the MockService, stop it and restart it, clearing any server side sessions. Now, rerun the test.

## Load Tests

Something very useful in soapUI is the ability to quickly create LoadTests. Why is this useful? The earlier you are able to run load tests, the earlier you can discover any performance issues. In soapUI you create a LoadTest simply by choosing a functional test, right clicking it and saying New LoadTest. Done!

This makes soapUI LoadTest extra good since the immediately enable you to load test the functionality not that the Web Service can respond quickly to the same Request over and over again. LoadTests are byproducts of the Functional Tests.

Now, let's examine a Load Test!

Go to the TestSuite Sample expanded TestSuite and the TestCase Search and Buy TestCase. There you will find for LoadTests, one for each LoadTest strategy. Choose the Simple Strategy LoadTest. The simple strategy is a basic strategy with a random delay.

The first figure to configure is the Test Delay, this sets the number of milliseconds our base delay will be (1000 is one second). The second figure is the random variable which sets how the delay should be changed at random, the value 0.5 means it should be half, that is between 500 and 1000 milliseconds.

What would the value 0 mean? That's right no random delay at all, just 1000 milliseconds all the time.

Now, let's run it!

As you see the numbers of the test are continuously updated. You can see figures like the response times throughput per second (tps) assertions errors and more. You can also press the graph button and see a graph of the test run.

Read more about the Interface here and the different strategies here.

You can also do LoadTest Assertions. One of the more important is the Max Errors Step. This is used for allowing the maximum number of errors allowed in a test run.

This will lead us to the final example, discovering an error in our MockService.

### An error in our MockService

Go to the TestSuite Sample TestSuite fails if we don't get faults and the TestCase TestCase: Searching after Logging out LoadTests. There you will find a load test called LoadTest with Multiple Tests (will fail). Open it and run it. After a time this test will fail

Why?

Because multiple users are simultaneously logging in with the same username, which is not allowed by the MockService

Go ahead, try it!

## Continuation

Now you can continue running the tests and look at different ways of doing tests.

Enjoy!