How to run specific testStep from LoadTestRunner

Please HELP, Ive have tried to figure out how to provide correct 'testRunner' and 'testRunContext' from loadTestRunner but cant figure it out (i.e.: loadTestRunner.loadTest.testCase.testSteps["TearDown"].run(loadTestRunner..[testRunner], context..[testRunContext])

My need for this is because we have not been successful in using the testCase.tearDown to perform cleanup of data consistantly when using either repetetive testCaseRunner or loadTestRunner so what I have dont is to convert the testCase.tearDown into a testStep['TearDown'] which I disable during loadTest.Setup and then re-enable during loadTest.TearDown BUT i *must* find a way to run the testCase.testStep['TearDown'] during the loadTest.tearDown... whew!!, got all that?? haha

What happens when you try to use the LoadTest TearDown script directly, rather than the TestStep?

/Nenad
http://eviware.com

We primarily use the testCase.TearDown for cleaning up data. The issue is that we dont want the case.TearDown  to run with every iteration of the LoadTest for the testCase.

I thought about using the setup of the loadtest to get current then set the wsdlTestCase.TearDownScript ="", then put the original back during loadTest.TearDown but didnt like that idea.
What I have done is to convert the testCase.tearDown into a testStep which is disabled/enabled during the loadTest.Setup/TearDown (respectively). Now I just need to be able to run that specific testStep during loadTest.TearDown so I dont have to run them manually after performing said loadTest.

hmm... I suppose I could copy the groovy from the testStep['TearDown'] into the loadTest.TearDown but would prefer to avoid that as it will be alot more code to manage.

Hello,

Something like this:

def testStep = loadTestRunner.loadTest.testCase.testSteps["IsValidEmail"]
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 )
testStep.run( runner, tscontext )

btw. why do not you set up a test case property, check its value at loadtest teardown and based on its value do some groovy script? you can change value of that property to point what kind of clean up is need.

robert

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:

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