Soap UI - Lesson45

Editor's Notes

• #4: First let’s review about XPaths
• #7: Contains - Searches for the existence of a string token in the property value, supports regular expressions. Applicable for any property. Message Content Assertion - Allows for complex content validation of XML messages. Applicable to any property containing XML. Not Contains - Searches for the non-existence of a string token in the property value, supports regular expressions. Applicable to any property.
• #9: Right click on the field that you want to verify, the click Add Assertion and select the type of assertion – in this case for Content
• #10: Automatically selects the Xpath for the field and selects the current value
• #12: Sometimes, we don’t care what is actually returned, we just want to make sure that a particular element is returned. Select any element and right-click to add assertion then select for existence.
• #13: Dialog box is prepopulated with the Xpath and the exists and the value of true – click ok and the assertion is added.
• #14: To verify that a soap (or non soap response) was returned, select the item from the list and click Add. No further configuration is needed.
• #15: To add assertion for soap fault or non-soap fault just select from the list and click Add, no further configuration is needed.
• #16: Some requests are time sensitive and must be processed within a certain amount of time, else they should be ignored – getting a stock price within 10 seconds is one of these, changing a password is another example- if it can’t be changed within 30 seconds, then it should be ignored. To add an assertion for response time, select SLA and click Add. Then enter the SLA time
• #17: For the Xpath or Xquery assertion, select the property content and then pick Xquery- Xpath is used to identify a specific node or element in the XML whereas Xquery is more list sql for XML stuctures
• #18: Click on the declare button will provide all of the namespace information, then just type in the path to the element. Then click on the select from current button it the expected result will be populated from the current response
• #19: Assertions can also be added with a groovy script. This example is for existence of the field and the script is auto generated – we will be covering scripts in more detail later
• #20: Security is another category of assertions that can be used to make sure that the message received doesn’t contain any sensitive information
• #21: There could be lots of sensitive information being passed in the web service requests – anything from tokens, to passwords, to personally identifiable information should be verified
• #22: -There are several predefined tokens in the preferences (under Global Sensitive Information Tokens) – these and others can be used in your assertion
• #23: If WS security is being used for passing messages, then you may want to add in assertions for verifying that the messages contain valid ws-addressing and security headers
• #26: These assertions were added in the individual test step, so they are part of the test step – if we wanted to create a set of assertions that were reusable then we need to add an assertion test step
• #27: If we create an assertion test step, then we first need to pick the source (which in this case is the first test step)
• #28: In the Assertion TestStep window, select two or more assertions by holding the CTRL key and clicking all desired assertions to be grouped together. They can then either be grouped by an AND or an OR. If AND Is picked, then all of the assertions have to return valid in order for the test step to pass; if OR is picked, then if at least one of the assertions returns as valid, then the test step will be valid
• #30: In the attachment tab of the request, we can add in the attachment file and then submit the request – the actual attachment goes over as binary
• #31: Even though this is a rest service, there are attachments that contact information on the image as well as the pdf it self. You click on the + button and navigate to the attachment – once selected it will fill in the information.
• #32: The Run TestCase TestStep presents a flexible approach to modularization; it executes the configured target TestCase optionally passing and retrieving properties before and after execution, for example you could use this to call a complex sequence of TestSteps to perform and validate a login procedure, passing the required credentials and receiving the resulting sessionid. The top two options are for selecting the actual target TestCase, the remaining options are related to property/session management and threaded execution. This is like if we had called the Login TestCase as if it were a method taking input arguments and returning the response
• #33: SoapUI Pro adds the possibility to have a central library of Groovy Classes that can be accessed from any script within SoapUI, which can be useful for centralizing common tasks and functionality and for creating SoapUI extensions
• #38: On the project level you can find the tabs at the bottom to access the setup and tear down scripts
• #39: On the Test Suite level, you can also find tabs for setup and tear down scripts
• #40: And also at the Test Case level there are tabs to access the scripts for setup and teardown
• #45: def groovyUtils = new com.eviware.soapui.support.GroovyUtils(context) def projectPath = groovyUtils.projectPath def folderName = projectPath + "/testData" def row = testRunner.testCase.testSteps["DataSource"].currentRow def allFiles = [] new File( folderName ).eachFile() { file -> if( file.name =~ /.txt/ ) { allFiles.add( file.name ) } } if ( (row + 1) <= allFiles.size ) { // output to the TestStep property called inputData result["inputData"] = new File( folderName + "/" + allFiles[row] ).text }
• #46: // Write the response from the "Test Request: login" TestStep to a file def currentUser = context.expand( '${#TestCase#currentUser}' ) def response = context.expand( '${Test Request: login#Response}' ) new File( "C:/Users/eviware/" + currentUser + "_response.txt" ).write( response ) // To use another charset than the default, do this instead: // new File( "C:/Users/eviware/" + currentUser + "_response.txt" ).write( response, "UTF-8" )
• #47: To save the result (request data, response data, response time, etc.) of every executed TestStep in a Project, create a Project EventHandler (Project Window > Events tab > Add new EventHandler) of typeTestRunListener.afterStep with the code above. The 2nd code snippet is to log the messages from all failed test cases
• #49: Groovy assumes the property is a string at first. The “+ 1” operation appends that onto the end of the string instead of incrementing the numeric value. By adding “as BigDecimal” to the end of the line to get the value, the string is converted to a number. After we increment the numeric value, then we can cast it back to a string.
• #52: Note however this will only return the data from one node – we want all the nodes
• #62: When updating a WSDL, the underlying contract changes may require changes to all messages related to a certain modification, for example if an element has been renamed or moved. Also, XPath expressions in assertions, property transfers and expansions, etc. may need to be updated to correctly reference updated elements. Right-click on the wsdl definition and select refactor definition. Always, always create a back up before you overwrite everything
• #65: Click next after mapping all of the nodes and then review and accept any changes to the XPath
• #66:  all visible projects are part of the current workspace. You can add as many projects as you want to a workspace, but can also easily switch between different workspaces allowing you to have different testing setups (for different systems, clients, etc), It can also help manage different releases for the same project. Select File > New Workspace and then enter a name
• #67: Right click on the workspace and select import projects to attach specific projects to a workspace. To switch between workspace, select File > Switch workspace
• #70:  all visible projects are part of the current workspace. You can add as many projects as you want to a workspace, but can also easily switch between different workspaces allowing you to have different testing setups (for different systems, clients, etc), It can also help manage different releases for the same project. Select File > New Workspace and then enter a name
• #71: Right click on the workspace and select import projects to attach specific projects to a workspace. To switch between workspace, select File > Switch workspace
• #74: Provide a name for each environment and copy endpoints (if you want- you can always edit them later)
• #75: The tabs below the Environment names allow you to change them as needed for each environment. Now the environment is available as a drop down on the test suite, test case editors