I'm using soapUI 3.6.1 and I want to test a SOAP-interface with a test structure like this:
MyWorkspace
MyProject
TestSuite
TestCase Single
TestStep 1
TestCase Loop
Properties #1
Groovy #1
Run TestCase Single
Properties #2
Groovy #2
Run TestCase Single
TestCase Single contains a bunch of requests that should be performed with the same account-id. TestCase Loop is supposed to call TestCase Single using different account-ids. The Properties * are supposed to change the account-id.
MyProject has a property accountId set up with value 1234. This should work as the default value for single testing of the test cases, i.e. TestCase Single.
Properties #1 and Properties #2 have accountId specified with different values.
The intention is to allow TestStep 1 to be executed alone or as part of TestCase Loop.
TestStep 1 has a common SOAP-body where the following is a parameter sent to the web-service:
<accId>${='${#accountId}' != '' ? '${#accountId}' : ${#Project#accountId}}</accId>
Groovy #1 and Groovy #2 look like this:
log.info('Using account ' + (context.expand('${#accountId}') != '' ? context.expand('${#accountId}') : context.expand('${#Project#accountId}')));
My problem now is that the Groovy-script writes the correct value of accountId (i.e., the one inside the loop), but the TestStep 1 always uses the value from the project. I want TestStep 1 to use the value of the loop.
For debugging purposes I also put the following into TestStep 1:
<!--
{#Project#accountId}: ${#Project#accountId}
{#TestSuite#accountId}: ${#TestSuite#accountId}
{#TestRunContext#accountId}: ${#TestRunContext#accountId}
{#TestRun#accountId}: ${#TestRun#accountId}
{#TestCase#accountId}: ${#TestCase#accountId}
{#TestStep#accountId}: ${#TestStep#accountId}
{#MockService#accountId}: ${#MockService#accountId}
{#Global#accountId}: ${#Global#accountId}
{#System#accountId}: ${#System#accountId}
{#Env#accountId}: ${#Env#accountId}
{#accountId}: ${#accountId}
context.accountId: ${=context.accountId}
modelItem.accountId: ${=modelItem.accountId}
request.accountId: ${=request.accountId}
context.expand(): ${=context.expand('${#accountId}')}
-->
I traced the network traffic with Wireshark and noticed that only ${#Project#accountId} returned a value.
What am I doing wrong here? How do I need to code the <accId>-element to send the correct value to the remote host?
Now I revisited this issue and I think I found the best possible solution, even though I don't understand why my initial attempt didn't work.
I changed the structure to this:
MyWorkspace
MyProject
TestSuite
TestCase Single
TestStep 1
TestCase Loop
Groovy #1
Run TestCase Single
Groovy #2
Run TestCase Single
In other words I got rid of the Properties and moved the logic into the Groovies:
context.getTestCase().getTestSuite().setPropertyValue("accountId_loop", "1720");
and the appropriate line in TestStep 1:
<accId>${='${#TestSuite#accountId_loop}' != '' ? '${#TestSuite#accountId_loop}' : ${#MyProject#accountId}}</accId>
Related
I have the xUnitFileImport scheduled job configured in my polarion project (as described in Polarion documentation) to import e2e test results (formatted to JUnit test results)
<job cronExpression="0 0/5 * * * ? *" id="xUnitFileImport" name="Import e2e Tests Results" scope="system">
<path>D:\myProject\data\import-test-results\e2e-gitlab</path>
<project>myProject</project>
<userAccountVaultKey>myKey</userAccountVaultKey>
<maxCreatedDefects>10</maxCreatedDefects>
<maxCreatedDefectsPercent>5</maxCreatedDefectsPercent>
<templateTestRunId>xUnit Build Test</templateTestRunId>
<idRegex>(.*).xml</idRegex>
<groupIdRegex>(.*)_.*.xml</groupIdRegex>
</job>
This works and I get my test results imported into a new test run and new test cases are created. But if I run the import job multiple times (for each test run) it creates duplicate test case work items even though they have the same name, which leads to this situation:
Is there some way to tell the import job to reference the existing testcases to the
newly created test run, instead of creating new ones?
What i have done so far:
yes I checked that the "custom field for test case id" in the "testing > configuration" is configured
yes I checked that the field value is really set in the created test case
The current value in this field is e.g. ".Login" as i don't want the classnames in the report.
YES I still get the same behaviour with the classname set
In the scheduler I have changed the job parameter for the group id because it wasn't filled. New value is: <groupIdRegex>e2e-results-(.*).xml</groupIdRegex>
I checked that no other custom fields are interfering, only the standard fields are set
I checked that no readonly fields are present
I do use a template for the testcases as supported by the xUnitFileImport. The testcases are successfully created and i don't see anything that would interfere
However I do have a hyperlink set in the template (I'll try removing this soon™)
I changed the test run template from "xUnit Build test" to "xUnit Manual Test Upload" this however did not lead to any visible change
I changed the template status from draft to active. Had no change in behaviour.
I tripple checked all the fields in the created test cases. They are literally the same, which leads to the conclusion that no fields in the testcases interfere with referencing to them
After all this time i have invested now, researching on my own and asking on different forums, I am ready to call this a polarion bug unless someone proves me this functionality is working.
I believe you have to set a custom field that identifies the testcase with the xUnit file you're importing, for the importer to identify the testcase.
Try adding a custom field to the TestCase workitem and selecting it here.
Custom Field for Test Case ID option in settings
If you're planning on creating test cases beforehand, note that the ID is formatted form the {classname}.{name} for a given case.
I'm trying to set a node value in all test step's requests xml of all test cases in a test suite.
The groovy script is in the first test case and I get an error (XmlException: Unexpected Element: CDATA) as soon as the script try to edit the same tag in the second test case.
def groovyUtils = new com.eviware.soapui.support.GroovyUtils( context )
def AlltestCases = testRunner.testCase.testSuite.project.testSuites[testRunner.testCase.testSuite.name]
0.upto(AlltestCases.getTestCaseCount()) {
AlltestCases.getTestCaseList().each{
it.getTestStepList().each{ if(it.getClass()==com.eviware.soapui.impl.wsdl.teststeps.WsdlTestRequestStep){
if(it.getName().toLowerCase().contains("verify")){
step = groovyUtils.getXmlHolder("${it.getName()}"+"#Request")
step.setNodeValue("//*:Name/text()", "\$"+"{#TestSuite#NAME_ID}")
step.updateProperty()
}
}
}
}
}
If I understand your question correctly, you want to "inject" a value in a number of requests?
I would advise against that. I would rather set some project property, and then let each of the requests simply use that particular variable.
The most important reason for me to prefer this approach, is to make it more tranparent what is happening in your testcase, should someone else at some point - like if you get a different job - would need to take over your SoapUI projects. Currently you have requests, which hold values that appear to come out of nowhere. I would advise to make it clear that the request contains some sort of variable, and where that variable comes from.
Besides you will then also get more flexibility. If a few reqeusts at some point changes the path or name of the entity you want to change, you will need to make your code above handle that kind of situation. Not so, if you are merely using a variable in each of your requests.
How to skips scenarios conditionally in Cucumber Java testing?
For different testing environement,different scenarios need to be skipped.
You can assign a tag for the scenarios and exclude those scenario using the tags with cucumber options.
For example,
Feature: Feature 1
#skipforenv2
Scenario: Testing 1
....
#skipforenv1
Scenario: Testing 2
....
Assume if you want to skip scenario "Testing 2" in environment 1 and scenario "Testing 1"in Environment 2 Then,
While running on Environment 1, you can pass the tag argument as ~#skipforenv1 (--tags #skipforenv1). if we use ~ symbol before tag then it will be skipped for that execution.
using command line, `-Dcucumber.options="--tags ~#skipforenv1"`
using runner class, `#CucumberOptions(tags={"~#skipforenv1"}, .....)`
While running on Environment 2, you can pass the tag argument as ~#skipforenv2 (--tags #skipforenv2). Scenario 2 will be skipped.
using command line, -Dcucumber.options="--tags ~#skipforenv2"
using runner class, #CucumberOptions(tags={"~#skipforenv2"}, .....)
In SoapUI, I have a host Test Case, which executes another external Test Case (with several test steps) using the "Run Test Case" test step. I need to access a response from the external TC from within my host TC, since I need to assert on some values.
I cannot transfer the properties since they are in XML. Could I get some pointers as to how I could leverage Groovy/SoapUI for this.
For Response you can use the below code.
testRunner.testCase.getTestStepByName("test step").testRequest.response.responseContent
In you external TC create another property and at the end of the TC use Transfer Property step to transfer your XML node to it. In your host TC, just read that property as you would any other.
I also had a look around to see if this can be done from Groovy. SoapUI documentation says that you need to refer to the external name of the testsuite / testcase:
def tc = testRunner.testCase.testSuite.project.testSuites["external TestSuite"].testCases["external TestCase"]
def ts = tc.testSteps["test step"]
But I could not find how to get at the Response after that.
In addition to Guest and SiKing answers, I share a solution to a problem that I've met:
If your step is not of type 'request' but 'calltestcase' you cannot use Guest answer.
I have a lot of requests contained each in a testCase and my other testCases call these testCases each time I need to launch a request.
I configured my request testCases in order to return the response as a custom property that I call "testResponse" so I can easily access it from my other testCases.
I met a problem in the following configuration :
I have a "calltestcase" step that gives me a request result.
Further in the test I have a groovy script that needs to call this step and get the response value
If I use this solution :
testRunner.runTestStepByName("test step")
followed by testRunner.testCase.getTestStepByName("test step").testRequest.response.responseContent
I'm stuck as there is no testRequest property for the class.
The solution that works is :
testRunner.runTestStepByName("test step")
def response_value = context.expand( '${test step#testResponse#$[\'value\']}' )
another solution is :
testRunner.runTestStepByName("test step")
tStep = testRunner.testCase.getTestStepByName("test step")
response = tStep.getPropertyValue("testResponse")
Then I extract the relevant value from 'response' (in my case, it is a json that I have to parse).
Of course it works only because I the request response as a custom property of my request test case.
I hope I was clear enough
I have a Test Case called "testCaseOne"
It contains three Test Steps:
"AMFrequestOne"
"propertyTransfer"
"AMFrequestTwo"
"AMFrequestOne" creates a database object.
"propertyTransfer" sends the ResponseAsXml to a temporary property in "testCaseOne" called "tempProp".
I need to reference "tempProp" in a script inside of "AMFrequestTwo"
I've tried the following
def temp = testRunner.testCase.getPropertyValue( "tempProp" )
but I get the error "No such property: testRunner for class: Script6" (number increments with tries)
Is this because in an AMF request "Script is invoked with log, context, parameters and amfHeaders variables" and testRunner is not recognized?
I know it seems odd, but is it possible to do this? I'm unable to use a specific xpath property transfer between the two AMF Requests as it's possible for the structure to change and I'm not always looking for the same node.
Used
def temp = context.testCase.getPropertyValue( "tempProp" )
instead of
def temp = testRunner.testCase.getPropertyValue( "tempProp" )
and this works fine.