ModelItems are the preliminary building blocks of a soapUI project. The elements such as projects, test suites, test cases, test steps, mock services, mock responses, and assertions are all implemented as ModelItems.
The com.eviware.soapui.model.ModelItem interface (http://www.soapui.org/apidocs/com/eviware/soapui/model/ModelItem.html) is the super interface which defines the general behavior of all soapUI model items.
When you get hold of a Model Item in your script, you can use the corresponding getters to retrieve values such as id, name, and description of a ModelItem.
For Example:
getRoomDetailsTestCase.name
ModelItems provide us with various methods to access parent and child entities.
Let's look at some methods in TestCase ModelItem that are frequently used to retrieve TestSteps in a TestCase:
1. getTestStepByName(String stepName): To retrieve a specific test step inside a TestCase.
2. getTestStepCount(): To get the TestStep count of a TestCase
3. getTestStepList(): To get list of TestSteps included in a TestCase
Add the following script as a Groovy Script TestStep in any of the TestSuites in the HotelReservation sample project and run the TestStep:
import com.eviware.soapui.impl.wsdl.teststeps.*
def getGuestDetailsTestCase = testRunner.testCase.testSuite.project.testSuites["GuestManagementServiceTestSuite"].testCases["getGuestDetails TestCase","Delay"]
//To get specific test
stepgetGuestDetailssoapStep = getGuestDetailsTestCase.getTestStepByName("getGuestDetails")
log.info("Name of the TestStep: "+getGuestDetailssoapStep.getLabel())
//To get test step
countlog.info("Number of TestSteps in getGuestDetails TestCase: "+getGuestDetailsTestCase.getTestStepCount())
//To get all test steps
for(teststep in getGuestDetailsTestCase.getTestStepList())
log.info("Name of the TestStep in getGuestDetails TestCase: "+teststep.getName())
Assuming that we have two TestSteps, getGuestDetails and Delay, in the getGuestDetails TestCase, the script log output will show results similar to the following:
INFO:Name of the TestStep: getGuestDetails
INFO:Number of TestSteps in getGuestDetails TestCase: 2
INFO:Name of the TestStep in getGuestDetails TestCase: getGuestDetails
INFO:Name of the TestStep in getGuestDetails TestCase: Delay
Once we get hold of the TestStep object as described above, we can try out many interesting things. Suppose we want to add an assertion to a specific step in a TestCase, we can obtain the required TestCase first, traverse through all the TestSteps of the TestCase and add the necessary assertion programmatically as shown in the following script:
import com.eviware.soapui.impl.wsdl.teststeps.*
def getGuestDetailsTestCase = testRunner.testCase.testSuite.project.testSuites["GuestManagementServiceTestSuite"].testCases["getGuestDetails TestCase"]
//Define the type of assertion
def soapAssertion ="SOAP Response"
//Retrieve all TestSteps in getGuestDetailsTestCase
for(testStep in getGuestDetailsTestCase.getTestStepList())
{
//Check whether the TestStep is a SOAP Request TestStep if(testStep instanceof WsdlTestRequestStep)
testStep.addAssertion(soapAssertion)
}
we accessed the child TestSteps of the getGuestDetails TestCase, the parent TestSuite can also be retrieved using getGuestDetailsTestCase.getTestSuite().
We looked into some preliminary methods of soapUI ModelItems which can be used to manipulate various elements and operations in a soapUI project. So far, we have worked with scripts which have been inside Groovy Script TestSteps. However, Groovy Script step is not the only place where you can write your script. There are more:
1. Setup and TearDown Scripts at TestCase, TestSuite level which can be used to initialize and clean up various resources used in a soapUI test
2. Load Script at project level which is used to run a script after loading the project
3. Script assertion to introduce arbitrary validation on response
4. MockService-specific scripts
Setup and TearDown scripts in soapUI
Setup and TearDown scripts can be used for many purposes. In particular, if you want to initialize something which is applicable for the whole TestSuite or TestCase, the Setup script will be the most appropriate option. Let's look at how we can initialize database connection in RoomManagementServiceTestSuite using Setup Script:
1. Right-click on RoomManagementServiceTestSuite and select Show TestSuiteEditor.
2. Select Setup Script at the bottom pane and add the following script:
import groovy.sql.Sql;
def DBdriver="com.mysql.jdbc.Driver"
def DBpath="jdbc:mysql://localhost:3306/HOTEL_RESERVATION_DB"def username='root'def password='root'
try {
DBconnection = Sql.newInstance(DBpath, username, password, DBdriver);
context.setProperty("dbConProp", DBconnection)
}
catch (Exception e) {
log.error "Could not establish connection to the database."
}
Here, we used Groovy SQL library to establish a database connection to our sample HOTEL_RESERVATION_DB. Once the connection is established, in order to use the connection from anywhere in the TestSuite, we set the connection as a context property, dbConProp:
3. Now, we can use this connection within the RoomManagementTestSuite. In order to demonstrate the usage of the connection, let's add a simple Groovy Script TestStep under the addRoom TestCase:
def statement = "insert into ROOM_T values(500, 'Luxury', 'Double')"
def DBCon = context.getProperty("dbConProp")
DBCon.execute(statement)
Here, we simply used the dbConProp context property to execute a SQL query. Run RoomManagementServiceTestSuite and query the ROOM_T table. You will find the query has been executed successfully.
Similarly, TearDown Scripts can be used to close database connections at the end of the TestSuite execution.
4. Click on the TearDown Script tab at the bottom pane of RoomManagementServiceTestSuite and add the following script to close the database connection:
def DBCon = context.getProperty("dbConProp")
DBCon.close()
Load Script at soapUI project level
If we need to do something common for the whole project, we can invoke a script at the project level. In the soapUI project view, you will find Load Script and Save Script tabs at the bottom pane, where you can specify a script at the project level and run it just after loading the project
In SOA testing, we usually need to use the same soapUI project in multiple environments. Before deploying the web services in the QA environment, developers may execute the whole set of test suites in the development environment.
Similarly, the same tests will be executed in the staging environment before moving the services into production. Usually, in all these cases, nothing but the service endpoints are changed. Therefore, it will be necessary to change all endpoint URLs when moving the TestSuites among different environments. To address that, we can use a simple Groovy script at the project level and run it before deploying the test in different test environments.
Assume the following are the URLs of three of our sample web services when they are deployed in the QA environment:
Let's look at how we can change the existing endpoints of the SOAP request TestSteps in our sample project when moving the test into the QA environment.
1. Right-click on HotelReservationProject and select Show Project View. Then click on the Load Script tab on the bottom pane to open the script editor.
2. Add the following script:
//Define three web service endpoints
def GuestQAEndpoint = "http://QAServer:8080/axis2/services/GuestManagementService"
def RoomQAEndpoint = "http://QAServer:8080/axis2/services/RoomManagementService"
def ReservationQAEndpoint = "http://QAServer:8080/axis2/services/ReservationService"
//Get all TestSuites inside HotelReservationProject
testSuiteList = project.getTestSuites()
//Iterate through each TestSuite
testSuiteList.each
{
//Rerieve a particular TestSuite by its name
testSuite = project.getTestSuiteByName(it.key)
//Get all TestCases inside particular TestSuite
testCaseList = testSuite.getTestCases()
//Iterate over each TestCase of a particular TestSuite testCaseList.each
{
//Retrieve specific TestCase by its name
testCase = testSuite.getTestCaseByName(it.key)
//We do not want to set endponts for all TestSteps in a TestCase.
// So, get only the SOAP Request TestSteps
soapTestStepsList = testCase.getTestStepsOfType(com.eviware.soapui.impl.wsdl.teststeps.WsdlTestRequestStep.class)
//Iterate over each SOAP Request TestStep in a TestCase soapTestStepsList.each
{
//Assign the relevant endpoint
if(testSuite.name == "GuestManagementServiceTestSuite")
{
it.properties['Endpoint'].value = GuestQAEndpoint
}
else if (testSuite.name == "RoomManagementServiceTestSuite")
{
it.properties['Endpoint'].value = RoomQAEndpoint
}else {
it.properties['Endpoint'].value = ReservationQAEndpoint }
}
}
}
We will not go through each line in the previous script as everything is explained as inline comments. Note that we used Groovy closure style looping and the keyword it (it.key) to get the specific TestCase and TestSuite names from the list objects.
3. Run the script by clicking on the green arrow icon at the upper-left corner of the Script window. Check the SOAP Request TestSteps of each TestSuite. You will notice that the default endpoints of all SOAP requests are changed accordingly.
The com.eviware.soapui.model.ModelItem interface (http://www.soapui.org/apidocs/com/eviware/soapui/model/ModelItem.html) is the super interface which defines the general behavior of all soapUI model items.
When you get hold of a Model Item in your script, you can use the corresponding getters to retrieve values such as id, name, and description of a ModelItem.
For Example:
getRoomDetailsTestCase.name
ModelItems provide us with various methods to access parent and child entities.
Let's look at some methods in TestCase ModelItem that are frequently used to retrieve TestSteps in a TestCase:
1. getTestStepByName(String stepName): To retrieve a specific test step inside a TestCase.
2. getTestStepCount(): To get the TestStep count of a TestCase
3. getTestStepList(): To get list of TestSteps included in a TestCase
Add the following script as a Groovy Script TestStep in any of the TestSuites in the HotelReservation sample project and run the TestStep:
import com.eviware.soapui.impl.wsdl.teststeps.*
def getGuestDetailsTestCase = testRunner.testCase.testSuite.project.testSuites["GuestManagementServiceTestSuite"].testCases["getGuestDetails TestCase","Delay"]
//To get specific test
stepgetGuestDetailssoapStep = getGuestDetailsTestCase.getTestStepByName("getGuestDetails")
log.info("Name of the TestStep: "+getGuestDetailssoapStep.getLabel())
//To get test step
countlog.info("Number of TestSteps in getGuestDetails TestCase: "+getGuestDetailsTestCase.getTestStepCount())
//To get all test steps
for(teststep in getGuestDetailsTestCase.getTestStepList())
log.info("Name of the TestStep in getGuestDetails TestCase: "+teststep.getName())
Assuming that we have two TestSteps, getGuestDetails and Delay, in the getGuestDetails TestCase, the script log output will show results similar to the following:
INFO:Name of the TestStep: getGuestDetails
INFO:Number of TestSteps in getGuestDetails TestCase: 2
INFO:Name of the TestStep in getGuestDetails TestCase: getGuestDetails
INFO:Name of the TestStep in getGuestDetails TestCase: Delay
Once we get hold of the TestStep object as described above, we can try out many interesting things. Suppose we want to add an assertion to a specific step in a TestCase, we can obtain the required TestCase first, traverse through all the TestSteps of the TestCase and add the necessary assertion programmatically as shown in the following script:
import com.eviware.soapui.impl.wsdl.teststeps.*
def getGuestDetailsTestCase = testRunner.testCase.testSuite.project.testSuites["GuestManagementServiceTestSuite"].testCases["getGuestDetails TestCase"]
//Define the type of assertion
def soapAssertion ="SOAP Response"
//Retrieve all TestSteps in getGuestDetailsTestCase
for(testStep in getGuestDetailsTestCase.getTestStepList())
{
//Check whether the TestStep is a SOAP Request TestStep if(testStep instanceof WsdlTestRequestStep)
testStep.addAssertion(soapAssertion)
}
we accessed the child TestSteps of the getGuestDetails TestCase, the parent TestSuite can also be retrieved using getGuestDetailsTestCase.getTestSuite().
We looked into some preliminary methods of soapUI ModelItems which can be used to manipulate various elements and operations in a soapUI project. So far, we have worked with scripts which have been inside Groovy Script TestSteps. However, Groovy Script step is not the only place where you can write your script. There are more:
1. Setup and TearDown Scripts at TestCase, TestSuite level which can be used to initialize and clean up various resources used in a soapUI test
2. Load Script at project level which is used to run a script after loading the project
3. Script assertion to introduce arbitrary validation on response
4. MockService-specific scripts
Setup and TearDown scripts in soapUI
Setup and TearDown scripts can be used for many purposes. In particular, if you want to initialize something which is applicable for the whole TestSuite or TestCase, the Setup script will be the most appropriate option. Let's look at how we can initialize database connection in RoomManagementServiceTestSuite using Setup Script:
1. Right-click on RoomManagementServiceTestSuite and select Show TestSuiteEditor.
2. Select Setup Script at the bottom pane and add the following script:
import groovy.sql.Sql;
def DBdriver="com.mysql.jdbc.Driver"
def DBpath="jdbc:mysql://localhost:3306/HOTEL_RESERVATION_DB"def username='root'def password='root'
try {
DBconnection = Sql.newInstance(DBpath, username, password, DBdriver);
context.setProperty("dbConProp", DBconnection)
}
catch (Exception e) {
log.error "Could not establish connection to the database."
}
Here, we used Groovy SQL library to establish a database connection to our sample HOTEL_RESERVATION_DB. Once the connection is established, in order to use the connection from anywhere in the TestSuite, we set the connection as a context property, dbConProp:
3. Now, we can use this connection within the RoomManagementTestSuite. In order to demonstrate the usage of the connection, let's add a simple Groovy Script TestStep under the addRoom TestCase:
def statement = "insert into ROOM_T values(500, 'Luxury', 'Double')"
def DBCon = context.getProperty("dbConProp")
DBCon.execute(statement)
Here, we simply used the dbConProp context property to execute a SQL query. Run RoomManagementServiceTestSuite and query the ROOM_T table. You will find the query has been executed successfully.
Similarly, TearDown Scripts can be used to close database connections at the end of the TestSuite execution.
4. Click on the TearDown Script tab at the bottom pane of RoomManagementServiceTestSuite and add the following script to close the database connection:
def DBCon = context.getProperty("dbConProp")
DBCon.close()
Load Script at soapUI project level
If we need to do something common for the whole project, we can invoke a script at the project level. In the soapUI project view, you will find Load Script and Save Script tabs at the bottom pane, where you can specify a script at the project level and run it just after loading the project
In SOA testing, we usually need to use the same soapUI project in multiple environments. Before deploying the web services in the QA environment, developers may execute the whole set of test suites in the development environment.
Similarly, the same tests will be executed in the staging environment before moving the services into production. Usually, in all these cases, nothing but the service endpoints are changed. Therefore, it will be necessary to change all endpoint URLs when moving the TestSuites among different environments. To address that, we can use a simple Groovy script at the project level and run it before deploying the test in different test environments.
Assume the following are the URLs of three of our sample web services when they are deployed in the QA environment:
- http://QAServer:8080/axis2/services/GuestManagementService
- http://QAServer:8080/axis2/services/RoomManagementService
- http://QAServer:8080/axis2/services/ReservationService
Let's look at how we can change the existing endpoints of the SOAP request TestSteps in our sample project when moving the test into the QA environment.
1. Right-click on HotelReservationProject and select Show Project View. Then click on the Load Script tab on the bottom pane to open the script editor.
2. Add the following script:
//Define three web service endpoints
def GuestQAEndpoint = "http://QAServer:8080/axis2/services/GuestManagementService"
def RoomQAEndpoint = "http://QAServer:8080/axis2/services/RoomManagementService"
def ReservationQAEndpoint = "http://QAServer:8080/axis2/services/ReservationService"
//Get all TestSuites inside HotelReservationProject
testSuiteList = project.getTestSuites()
//Iterate through each TestSuite
testSuiteList.each
{
//Rerieve a particular TestSuite by its name
testSuite = project.getTestSuiteByName(it.key)
//Get all TestCases inside particular TestSuite
testCaseList = testSuite.getTestCases()
//Iterate over each TestCase of a particular TestSuite testCaseList.each
{
//Retrieve specific TestCase by its name
testCase = testSuite.getTestCaseByName(it.key)
//We do not want to set endponts for all TestSteps in a TestCase.
// So, get only the SOAP Request TestSteps
soapTestStepsList = testCase.getTestStepsOfType(com.eviware.soapui.impl.wsdl.teststeps.WsdlTestRequestStep.class)
//Iterate over each SOAP Request TestStep in a TestCase soapTestStepsList.each
{
//Assign the relevant endpoint
if(testSuite.name == "GuestManagementServiceTestSuite")
{
it.properties['Endpoint'].value = GuestQAEndpoint
}
else if (testSuite.name == "RoomManagementServiceTestSuite")
{
it.properties['Endpoint'].value = RoomQAEndpoint
}else {
it.properties['Endpoint'].value = ReservationQAEndpoint }
}
}
}
We will not go through each line in the previous script as everything is explained as inline comments. Note that we used Groovy closure style looping and the keyword it (it.key) to get the specific TestCase and TestSuite names from the list objects.
3. Run the script by clicking on the green arrow icon at the upper-left corner of the Script window. Check the SOAP Request TestSteps of each TestSuite. You will notice that the default endpoints of all SOAP requests are changed accordingly.
No comments:
Post a Comment