How to run specific testStep from LoadTestRunner
how to run a specific testStep from the setup or teardown of a LoadTest?
Forum Discussion
A very good idea Robert, to use a flag, but for my needs is not suitable. The main reason is that in some testCases we use the TearDown for extra validation and often time, this extra validation would be duplicated using both a TestCase and TearDown *but* the TearDown Script cannot fail a testCase via 'assert' whereas a testStep["TearDown"] script can.
Also, once the testCases (i.e. integration tests) are all passing properly (using a TestStep as a TearDown so we can confirm additional assertions in many cases) we will use these for LoadTests (until we develop targeted LoadTests) which should not run a TearDown with each iteration but only when LoadTest completes. Your response helped me to resolve this piece.
To complicate things further, our service works with multiple (duplicate) backends (i.e. 1 or more for each customer) and we wanted to be able to loadTest using this scenario. I had already incorporated such using the "ThreadIndex" in combination with property expansion to allow setting particular set of service-credentials, teardown-db-connection, etc for each thread (i.e. Thread1 = cust1db1, Thread2 = cust2db2, ... Thread100 = cust100db100).
For this ive added a loop in the TearDown of the LoadTest to run the testStep["TearDown"] for each thread, setting the ThreadIndex first:
This turns out to be overkill when we are running a scenario that splits 2 customers between 100 threads (i.e. t1=x, t2=y, t3=x, t4=y, ...) but hey, its a TearDown of a LoadTest so we already go the critical data we were after before we reached the TearDown phase
If you have any other suggestions Robert Id love to hear them, you never know what could be beneficial.
SO@PU!R0CK5
Also, once the testCases (i.e. integration tests) are all passing properly (using a TestStep as a TearDown so we can confirm additional assertions in many cases) we will use these for LoadTests (until we develop targeted LoadTests) which should not run a TearDown with each iteration but only when LoadTest completes. Your response helped me to resolve this piece.
To complicate things further, our service works with multiple (duplicate) backends (i.e. 1 or more for each customer) and we wanted to be able to loadTest using this scenario. I had already incorporated such using the "ThreadIndex" in combination with property expansion to allow setting particular set of service-credentials, teardown-db-connection, etc for each thread (i.e. Thread1 = cust1db1, Thread2 = cust2db2, ... Thread100 = cust100db100).
For this ive added a loop in the TearDown of the LoadTest to run the testStep["TearDown"] for each thread, setting the ThreadIndex first:
def testStep = loadTestRunner.loadTest.testCase.testSteps["TearDown"]
def runner = new com.eviware.soapui.impl.wsdl.testcase.WsdlTestCaseRunner(loadTestRunner.loadTest.testCase, null)
def tsContext = new com.eviware.soapui.impl.wsdl.testcase.WsdlTestRunContext( testStep )
def threadCount = loadTestRunner.loadTest.getThreadCount()
for(threadNum in 0..threadCount)
{
tsContext.setProperty("ThreadIndex", threadNum)
testStep.run( runner, tsContext )
}
This turns out to be overkill when we are running a scenario that splits 2 customers between 100 threads (i.e. t1=x, t2=y, t3=x, t4=y, ...) but hey, its a TearDown of a LoadTest so we already go the critical data we were after before we reached the TearDown phase
If you have any other suggestions Robert Id love to hear them, you never know what could be beneficial.
SO@PU!R0CK5
