This lesson covers advanced strategies that will help you develop more robust, reusable test suites.

Sections include:

Creating Reusable (Modular) Test Suites

In many cases, you may want to create a test suite that can be reused by other test suites. A common example is a test suite that logs into a website. Once such a test suite is created, it can be used by other test suites in various scenarios that require a login.

Two SOAtest features are especially helpful for the creation and use of reusable test suites:

Referenced test suites: Once a reusable module or test suite has been created, it can be referenced by another test suite.
Variables: You can parameterize tests with variables, which can be set to specific values from a central location, extracted from a test (for example, through a data bank tool), or set from data sources.

This lesson demonstrates how those two features can be used to create and use reusable test suites. For simplicity, we will use the store web service; however, the principles and steps below can then be applied to any scenario that you create.

To create a reusable test suite:

Create an empty test suite (.tst) file called ReusableModule.tst as follows:
1. Right-click the Examples project node in the Test Case Explorer, then choose Add New > Test (.tst) file.
2. Under File name, enter ReusableModule.
3. Click Next.
4. Select Empty, then click Finish.
Create a SOAP Client test as follows.
1. Expand the ReusableModule.tst Test Case Explorer node.
2. Right-click the Test Suite: Test Suite node, then choose Add New > Test.
3. In the dialog that opens, choose SOAP Client, then click Finish.
Configure the SOAP Client test as follows:
1. Click the WSDL tab and enter http://localhost:8080/parabank/services/store-01?wsdl for the WSDL URL.
2. Click the Request tab and choose getItemByTitle from the Operation dropdown.
3. Save the changes to the SOAP Client tool.
Define a variable as follows:
1. Double-click the Test Suite: Test Suite node to open the test suite configuration panel.
2. Click the Variables tab and click Add.
3. In the dialog’s Name field, enter title variable.
4. Choose String from Type dropdown.
5. Keep the selection at Use value from parent test suite (if defined). This will allow the variable to use values set in the test suite that references this test suite. If the selection is changed to Use local value, the value of the variable will always be the value specified in the Value field.
6. In the Value field, enter PowerBuilder. This is the default value that will be used if SOAtest does not find a data source named store with a column named title.
7. Click OK.
8. Save the test suite configuration changes.
Configure the SOAP Client test to use the specified data source values, if available, as follows:
1. In the SOAP Client’s test configuration panel, go to the Request tab, enable titleKeyword and choose Parameterized and title variable from the dropdown menus.
2. Save the changes to the SOAP Client tool.
Run the test suite by click ReusableModule.tst, then clicking the Run Test on the tool bar.
Double-click the SOAP Client test’s Traffic Viewer node to see the traffic. Note that the titleKeyword used was PowerBuilder. SOAtest used the default variable value because it did not find the specified data source (since we did not create it yet).
Create an empty test suite (.tst) file called TestStoreTitles.tst as follows:
1. Right-click the Examples project node in the Test Case Explorer, then choose Add New > Test (.tst) file.
2. Under File name, enter TestStoreTitles.
3. Click Next.
4. Select Empty, then click Finish.
Define a variable as follows:
1. Double click the TestStoreTitles.tst > Test Suite: Test Suite node to open the test suite configuration panel.
2. Click the Variables tab and click Add.
3. In the dialog’s Name field, enter title variable.
4. Choose Data Source from the Type dropdown.
5. Enter store for Data SourceName and enter title for Column Name.
  
  Note that this test variable will override the string test variable that is defined in the reference .tst file.
Click OK.
Add a data source to that test suite as follows:
1. Right-click the TestStoreTitles.tst > Test Suite: Test Suite node and choose Add New > Data Source.
2. Select Table and click Finish.
3. In the data source configuration panel, change the data source name to store.
4. Enable First row specifies column names.
5. Add a column named title.
6. Add two values to that column: Linux and C++.
7. Save the data source changes.
Configure this test suite to reference the first test suite we created in this exercise as follows:
1. Right-click TestStoreTitles.tst > Test Suite: Test Suite and choose Add New > Test Suite.
2. Choose Reference Test (.tst) File.
3. Click Next.
4. Select the ReusableModule.tst file from your SOAtest workspace.
5. Click Finish.
Run the current test suite by clicking TestStoreTitles.tst, then clicking Run Tests on the tool bar.
Double-click the Traffic Viewer node to see the traffic.
Verify that Linux, then C++ were used as the titleKeyword.

Looping Until a Test Succeeds or Fails - Using Test Flow Logic

In many cases, you may want to have SOAtest repeatedly perform a certain action until a certain condition is met. Test suite flow logic allows you to configure this.

SOAtest allows you to choose between two main test flow types:

While variable: Repeatedly perform a certain action until a variable condition is met.
While pass/fail: Repeatedly perform a certain action until one test (or every test) in the test suite either passes or fails (depending on what you select in the "loop until" settings). Note that if you choose this option (for instance, with it set to loop until one of the tests succeeds) and the overall loop condition is met (for example, one test succeeds), then tests that had failures will be marked as succeeding. If the overall loop condition is not met (for example, no tests succeed), then the individual tests that failed will be marked as failed. The console will show which tests passed and which tests failed, regardless of whether or not the loop condition is met.

To see how while pass/fail logic allows you to have a test suite loop until a specified price value is reached.

Create an empty test suite (.tst) file called TestFlowLogic.tst as follows:
1. Right-click the Examples project node in the Test Case Explorer and choose Add New > Test (.tst) file.
2. Under File name, enter TestFlowLogic.
3. Click Next.
4. Choose Empty, then click Finish.
Open the test suite configuration panel by expanding the test suite and double-clicking the Test Suite: Test Suite node.
Go to the Execution Options > Test Flow Logic tab.
Choose While pass/fail from the Flow type dropdown.
Enter 20 in the Maximum number of loops field.
Change the Loop until setting to One test and Succeeds.
Save the test suite configuration settings.
Create a SOAP Client test as follows.
1. Right-click the TestFlowLogic.tst > Test Suite: Test Suite node and choose Add New > Test.
2. In the dialog that opens, choose SOAP Client and click Finish.
Configure the SOAP Client test as follows:
1. Click WSDL tab and enter http://localhost:8080/parabank/services/store-01?wsdl for the WSDL URL.
2. Click the Request tab and choose getItemByTitle from the Operation dropdown.
3. Enable titleKeyword then choose Fixed and enter PowerBuilder as the value.
4. Save the changes to the SOAP Client test.
Create a regression control for that test as follows:
1. Right-click the SOAP Client test node and choose Create/Update Regression Control.
2. Choose Create Regression Control.
3. Click Finish.
Modify the expected price in the regression control as follows:
1. Double-click the newly created Diff control node to open the Diff tool editor.
2. Modify the value in the price element. The store service increases the price of the book by $1.00 after several calls to getItemByTitle, so depending on how many times you’ve ran tests in this tutorial, the current price may be different than shown.
Run the current test suite by selecting the test suite node, then clicking Run Tests on the tool bar. Even though specific tests failed, the test suite will succeed because the price entered in the expected response will be reached before looping 20 times. You can see this in the Console tab:
Higher prices than expected?
The more times you’ve called getItemByTitle, the more the prices will have increased. To bring prices back down, restart the Parabank server and rerun the SOAP Client that calls getItemByTitle.
Double click the previously created Diff Control node to re-open the Diff tool editor.
Modify the price so that the test will loop the full 20 times before the price is reached.
Run the Test Suite again. The Test Suite will fail because the price is never reached after looping 20 times.

Extending SOAtest with Scripting

If you have a testing requirement which requires you to add custom functionality or logic to your test cases, SOAtest allows you to easily integrate custom scripts into your testing environment.

Using SOAtest’s XML Assertor, you can integrate custom scripts written in into SOAtest. This means that almost any testing situation can be handled with ease, even if the situation is not directly supported by SOAtest’s current tool set.

In this example you will create a Scenario Test using the bookstore service used in previous examples. In this Scenario you will search for a book by its title, then validate that the price of the book is an even integer.

When you complete this section of the tutorial, your test suite should resemble the test suite entitled "Custom Scripting" in the SOAtestTutorial.tst file.

Click the Test Suite: Functional Tests node (created in Creating Test Suites for Unit Tests) and click Add Test Suite on the tool bar.
In the Add Test Suite wizard, choose Empty and click Finish.
Double-click the new Test Suite: Test Suite node added to the test suite tree, enter Custom Scripting in the Name field in the test configuration panel, then click Save.
Click the Test Suite: Custom Scripting node and click Add test or output on the tool bar.
In the Add Test wizard, choose SOAP Client in the right and click Finish. A SOAP Client tool is added to the test suite.
Double-click the Test 1: SOAP Client node underneath the Test Suite: Custom Scripting node and enter Validate Price Value in the Name field in the right GUI Panel.
Click the WSDL tab and enter http://localhost:8080/parabank/services/store-01?wsdl in the WSDL URL field.
Click the Request tab and choose getItemByTitle from the Operation dropdown.
Click the SOAP body tab, click getItemByTitle and enable titleKeyword.
Choose Fixed from the drop-down menu and enter Linux as the value.
Click Save on the tool bar.
Right-click the Test 1: Validate Price Value node and choose Add Output.
In the Add Output wizard, choose Response > SOAP Envelope on the left and XML Assertor on the right, then click Finish. This tells SOAtest to chain an XML Assertor to the XML Response output of the SOAP Client.
Click the Configuration tab within the XML Assertor test configuration panel and click Add.
In the Select Assertion dialog, expand the Value Assertion node and choose Custom Assertion, then click Next.

The Custom Assertion dialog then displays a tree view of the XML message from which you can select a single value to enforce.
Click the price element in the XML tree view and click Finish.

The test configuration tab will now be populated with a Custom Assertion.
Choose Jython from the Language drop-down menu.
Enter the following script, which ensures that the price value is even, in the Text field of the test configuration tab:
```
def checkPrice(input, context):
	price = float(input)
	if price % 2 == 0:
		return 1
	else:
		return 0
```
Select checkPrice() from the Method drop-down menu.
Click Save on the tool bar.
Select the Test 1 node and click Run Tests on the tool bar. Notice that the test fails. If you double-click the test’s Traffic Viewer node, you will see that the price of the Linux book is an odd number, causing the test to fail.

Further Extending SOAtest

SOAtest’s built-in extensibility framework can be used in your scripts, allowing for the definition and use of custom transport protocols and message implementations within SOAtest. For more information, go to Parasoft > Help > Parasoft SOAtest Extensibility API.

Page tree

Advanced Strategies

Creating Reusable (Modular) Test Suites

Looping Until a Test Succeeds or Fails - Using Test Flow Logic

Extending SOAtest with Scripting

Further Extending SOAtest