Contributions
Composite Project Directory/File names
My issue is similar to this one: viewtopic.php?f=20&t=12856&p=31392 The operations I am testing have '_' within the service and some operation names. Prior to v4 the directories and files created by Soapui stripped all but alphanumeric chars from both (i.e. DataService_v2_0 -> DataServicev20). Sometime in v4 it began inserting the '_' in all directory/filenames and I have to update my source control (big big pita) Now, running some stuff in v4.5 and trying to save a project it seems to be stripping the '_' back out again?!? This changing back and forth is causing me a lot of extra work and headaches .... Is this a new bug or is it being changed back to only doing alphanumeric? What is your intended standard for directory/filenames (so I know when I should change our source control OR when to fix SoapUI directory/filenames)?12 years agoPlace ReadyAPI QuestionsReadyAPI Questions2.1KViews0likes1Comment- 13 years agoPlace ReadyAPI QuestionsReadyAPI Questions1.6KViews0likes0Comments
Re: Complex project creates many unnecessary tmp files
I get this every time I "save all projects in workspace" OR right click 'save' individual projects (tmp files created & errors only for specific project being saved). What else might help you solve this?14 years agoPlace ReadyAPI QuestionsReadyAPI Questions3.5KViews0likes0CommentsRe: Complex project creates many unnecessary tmp files
I also have this issue (3.5.1 Build dist-97-2010-04-12, Build Date 2010/04/12 09:51)... I would suggest that SoapUI not open/import those files *if* it finds them (due to not being removed from previous shutdown/exit-error) Also, it would be even better if SoapUI set these files to hidden which would make managing source control much easier (or even better would be to put them into a completely separate temp directory i.e. c:\temp\soapui...)14 years agoPlace ReadyAPI QuestionsReadyAPI Questions3.5KViews0likes0CommentsRe: Duplicate Testcases
We do have a large number of test cases and have not experienced any duplication. As we are moving to a new Version Control I have experienced deleted/renamed test-suites/cases/steps re-appearing but it was due to being marked read only, or deleted by soapui only to be re-created by our new version control...15 years agoPlace ReadyAPI QuestionsReadyAPI Questions2.3KViews0likes0Comments"Comment" testStep
Id like to have testSteps which have no other purpose than to break up the list of testSteps, kind of like an hr (horizontal rule). They could also accept a comment as the step data. The reason for this is we have some testCases which contain over 40 steps and something like this would be very useful for breaking it into 'sections'.15 years agoPlace ReadyAPI QuestionsReadyAPI Questions2.4KViews0likes1CommentRe: How to run specific testStep from LoadTestRunner
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!R0CK515 years agoPlace ReadyAPI QuestionsReadyAPI Questions2.4KViews0likes0Comments