ContributionsMost RecentMost LikesSolutionsRe: ReadyAPI - Organize test steps into blocks ? Hi, I tend to use a Delay Test Step to achieve this. Create a Delay Test step, rename it to whatever and set the delay value to 0. Not a perfect solution, but workable. Re: Run two copies of ReadyAPI (SoapUI Pro) simultaneously Hi, Sorry to hear you managed to corrupt workspaces on occasion. Following the steps above, I've been able to happily run two sessions (with different workspaces) across several version of SoapUI. Never had an issue. Re: Getting Assertion Renaming Box while adding Script assertion using Groovy Script. How to avoid it? Hi, I have not actually tried adding an assertion step from Groovy Script, but it looks like you should create it with the new name, instead of creating then setting it. I suspect you have another script in your test step called 'Script Assertion'. Instead of... // Add the new script assertion. def testAssertion = testStep.addAssertion('Script Assertion') testAssertion.setName(newAssertionName) try // Add the new script assertion. def testAssertion = testStep.addAssertion(newAssertionName) //testAssertion.setName(newAssertionName) Re: End of my data driven test > Ending with an Exception "Type Mismatch" Hi, The only thing I can think of here is that Test Complete 'thinks' that it should process row 5. If your source data is in CSV format, open it in Notepad and check for a <cr> at the end of the last line. Another thing worth trying... In your DataDrivenLoop step, does it allow you to see the data? Might be worth seeing how rows the app thinks it needs to process. Re: ReadyAPI - Creating shared test data for a suite or project? Hi, Based on what you have described, I would say a data driven test using datasource and loop steps are the way to go. Re: Run two copies of ReadyAPI (SoapUI Pro) simultaneously Hi, I'm running Ready API 2.7.0 (licensed) and I do run two sessions quite often for the very same purposes you describe. I've also had the 'opened in another session' type warning, so I do this... This is based on two separate workspaces, say 123 and ABC Start with no sessions running. Start Ready API and let it load up whatever is the last used workspace, say ABC. Once Session 1 is running, make no changes at all. Start Session 2, this too will load workspace ABC. Once loaded, you have two sessions with ABC. In Session 2, select Switch Workspace and select workspace 123. Session 2 asks whether to save changes. Say No, otherwise Session 1 will have conflicts. Workspace 123 should then be loaded. Once you have two sessions with different workspaces, you should be good test in parallel and save changes to both workspaces. Re: Script assertion to find string value in response Hi Behdad, Would you like to share what you have so far? Chris Re: Cannot access a global variable in custom authorization profile. Hi, A few screenshots showing how you are trying to access this Global variable would be really useful. Chris Re: Sub : how to do regular expression assertions for variable elements in an array Hi, Add a script assertion to the test step of interest. The below will get you started, but be warned, it won't work first time. You will need to tailor this to your needs. import groovy.json.JsonSlurper import groovy.json.* import java.util.regex.* // User Json Slurper to get the JSON from the response. def jsonSlurper = new JsonSlurper().parseText(messageExchange.response.responseContent) // Just log how many items to check. If you get an error here, replace message with // root node of interest in the response. log.info("Checking ${jsonSlurper.message.size()} items in response."); // Let's iterate over the array of items... jsonSlurper.message.each{ // Have a look at the current items log.info("Item. Code ${it.code}. Unit ${it.unit}.); // Check it.code for numeric only. if (it.code.matches("[0-9]+") && it.code.length() > 0) { log.info("Code ${it.code} passes"); } else { log.info("Code ${it.code} fails") } // Check it.unit for lowercase chars only. if (it.unit.matches("[a-z]+") && it.unit.length() > 0) { log.info("Code ${it.unit} passes"); } else { log.info("Code ${it.unit} fails") } // You decide how to report failure. E.g. dump to a file // or assert. } Re: Multiple testing parameters from external file Hi, richiehas come up with a good workaround. The functionality you want is actually standard in the licensed version. It might be worth running the Pro Trial to see if the functionality meets your needs. Chris