Contributions
Re: Long delay causes test to hang
So, I've gone through several iterations rearranging and running tests, and I think I may have discovered a way to get my tests to run without hanging or crashing. My latest permutation breaks out any delay longer than 30 seconds to its own test suite. I've run several times without any SoapUi issues. I'm not sure if the problem happens when a test suite runs for too long or if it's because there are several long delays spread out over one test suite, but it did hang pretty reliably before I changed it to the current strategy. It's an interesting problem that I'd like to spend more time testing to find the specific combination that reproduces it, but SmartBear doesn't pay me enough for that. XD3.1KViews0likes1CommentRe: Long delay causes test to hang
Ah, hmm. Well, the part of the project that is the flow I enumerated is generated by a groovy script based on a csv file. Let me see if I can step through the rules for test suites, cases, and steps and give you a more complete picture. Test suite 1: 34 parallel setup test cases with 1 soap request test step each Test suite 2: 1 case, 1 step: 20 second delay Test suite 3: 34 parallel start test cases with 1 soap request test step each ___ Following block pattern repeats 6X (with different requests) | Test suite 4: | 1 case, 1 step: 13 minute delay | 1 service operation test case with 1 soap request test step | 1 case, 1 step: 3 second delay | 1 service status test case with 1 soap request test step | | 1 case, 1 step: 13 minute delay | 1 service operation test case with 1 soap request test step | 1 case, 1 step: 3 second delay | 1 service status test case with 1 soap request test step | | 1 case, 1 step: 13 minute delay | 1 service operation test case with 1 soap request test step | 1 case, 1 step: 3 second delay | 1 service status test case with 1 soap request test step | | 1 case, 1 step: 13 minute delay | 1 service operation test case with 1 soap request test step | 1 case, 1 step: 3 second delay | 1 service status test case with 1 soap request test step | | 1 case, 1 step: 13 minute delay | 1 service operation test case with 1 soap request test step | 1 case, 1 step: 3 second delay | 1 service status test case with 1 soap request test step | End test suite 4 | | Test suite 5: | 1 case, 1 step: 13 minute delay | 34 parallelservice status test cases with 1 soap request test step each | End test suite5 ------ End block pattern Test suite 16:34parallel service tear down test cases with 1 soap request test step each3.1KViews0likes0CommentsRe: Long delay causes test to hang
I'll enumerate the general flow of the tests to give you a better idea of what's happening. I have about 34soap requests at the beginning that basically set up some services. At the end I have about 34 soap requests that tear down the services. In between I have groups of a few operations separated by delays of 13 minutes. In all, there are 37of these groups, resulting in a test that will run for about 8 hours. Generally, the groups are just 2 requests that get executed in serial, but there are 6 groups of 34 parallel requests spaced evenly throughout the test that are basically checking status on the services. Like so: 34 parallel setups 20 second delay 34 parallel starts ___ Following block pattern repeats 6X (with different requests) | 13 minute delay | 1 service operation request | 3 second delay | 1 service status request | | 13 minute delay | 1 service operation request | 3 second delay | 1 service status request | | 13 minute delay | 1 service operation request | 3 second delay | 1 service status request | | 13 minute delay | 1 service operation request | 3 second delay | 1 service status request | | 13 minute delay | 1 service operation request | 3 second delay | 1 service status request | | 13 minute delay | 34 parallelservice status requests ------ End block pattern 34parallel service tear downs3.1KViews0likes2CommentsRe: Long delay causes test to hang
I do have access to SoapUI 5.2.1, but it is currently not approved for my use. If it's something that can be worked around in 4.5.1, that would be ideal. If not, I may have no choice but to slog through getting the newer version approved, assuming it doesn't exhibit the same behavior.3.1KViews0likes0CommentsLong delay causes test to hang
I'm currently using SoapUI 4.5.1 testrunner.sh to run some duration tests over the course of 8 hours on the command line. I have a few requests separated by delay test steps of 13 or so minutes. The test always hangs at some point while running, though not always in the same place and not always on the delays. When I put the delays down to 2 seconds, the test runs all the way through to the end just fine. I have tried replacing the delay test steps with groovy steps that call Thread.sleep. I have even tried breaking the delays up into individual groovy test steps that sleep for 30 seconds until the desired delay has been achieved. So far none of these attempts have not resulted in failure. Is this a known issue? Is there a workaround? ThanksSolved3.2KViews0likes8CommentsRe: Log output from tests added with Groovy
So, I figured it out on my own. I'll post the resolution just in case someone else finds it useful. Let me start with a more precise description of the problem: If you have a project that contains groovy code that adds a test case with requests in it, the default log output you would normally get with such a test case is absent when the test case runs. Specifically, this is the logoutput in the "soapUI log" area in the GUI, which also gets printed when running on the command line with testrunner.sh. import com.eviware.soapui.impl.wsdl.teststeps.assertions.soap.SoapResponseAssertion import com.eviware.soapui.impl.wsdl.teststeps.assertions.soap.NotSoapFaultAssertion import com.eviware.soapui.impl.wsdl.teststeps.registry.WsdlTestRequestStepFactory import com.eviware.soapui.impl.wsdl.testcase.WsdlTestCase import com.eviware.soapui.impl.wsdl.* import groovy.util.slurpersupport.GPathResult import groovy.xml.XmlUtil WsdlProject project = context.testCase.testSuite.project // Add test suite/case WsdlTestSuite ts = project.addNewTestSuite("My Test Suite") WsdlTestCase tc = ts.addNewTestCase("My Test Case") // Build a request from an interface operation WsdlInterface intfc = project.interfaces["someWsdlInterfaceBinding"] WsdlOperation op = intfc.getOperationByName("someWsdlOperation") String requestString = op.createRequest(true).toString() GPathResult envelope = new XmlSlurper().parseText(requestString) // Now you can populate values in the request envelope if necessary GPathResult body = envelope.Body["someWsdlOperation"] body.someNode = "someText" body.someNestedNode.someChildNode = "someMoreText" // Create the WsdlRequest and add your content WsdlRequest request = operation.addNewRequest("My New Request") XmlUtil xmlUtil = new XmlUtil() requestString = xmlUtil.serialize(envelope) request.setRequestContent(requestString) // Now, add a request test step with your request to the new test case def config = WsdlTestRequestStepFactory.createConfig(request, "My New Test Step") def ts = tc.insertTestStep(config, -1) // Add some assertions to the new step ts.testRequest.addAssertion((new SoapResponseAssertion.Factory()).getAssertionLabel()) ts.testRequest.addAssertion((new NotSoapFaultAssertion.Factory()).getAssertionLabel()) The above code will add the new test suite/case/step to your project, which will immediately run after the groovy step completes. But once the new test case runs, you will notice the only output you see is that the request was sent and the response received. It will not output when it starts/finishes the test case nor whether or not the assertions passed. The reason for this is that there is a set of listeners that gets added to each test case once the project is run. These listeners are responsible for the normal test case output and any assertion output that you would normally see in the soapUI log. Any test case added after the project starts to run does not contain these listeners and, therefore, lacks the log output. The solution, then, is to add these listeners to any new test case dynamically added to the project. Don't worry, though, you don't have to know specifically which listeners or how to instantiate them. Just copy the ones from your groovy step's test case. ... // Add test suite/case WsdlTestSuite ts = project.addNewTestSuite("My Test Suite") WsdlTestCase tc = ts.addNewTestCase("My Test Case") // Add listeners to your new case context.testCase.testRunListeners.each { tc.addTestRunListener(it) } ... Now you will see the normal log output in the soapUI log and on the command line for your new case.1.8KViews3likes1CommentLog output from tests added with Groovy
Hi, I have a SoapUi project with a Groovy test step that generates a series of test suites from a CSV. The idea is that each suite would have a set of request steps with a different request type from our wsdl. It all works well, however when running from the command line with testRunner, the normal log output that you would get from test suites that were already in the project don't appear. Only a log message that it was sending the request and received the response. The requests are all generated with, at a minimum, Soap Response and Not Soap Fault assertions, but even this output does not appear. I assume this is because the test suites were added after the project starts running and, perhaps, that the log only prints for test suites/cases/steps that were already there when it started. Is there a way around this?Solved1.9KViews0likes2CommentsRe: testrunner.sh -m option
Rao, Thanks, I had seen that page before, but I guess I didn't study the lower part closely enough to realize that it shows how testrunner is invoked with the options selected in the GUI. Unfortunately, I don't see in that dialog anything related to the maximum number of failures to export (the -m option). It's likely that I'm just selectively blind, though. Is there such an option in this dialog? Thanks again!1.6KViews0likes0Commentstestrunner.sh -m option
Hi, I'm running soapUI 4.5.1 and was running some test projects from the command line using testrunner and ran into an issue. Not sure if this is a bug or user error and I don't see this question anywhere else in the forums, so I thought I'd ask about it. Basically, this is what I'm running on my linux machine: user@linuxbox:soapui_tests$ /apps/soapui_4.5.1/bin/testrunner.sh -m 0 MyWs_TestProject.xml And what I get from that is the testrunner usage list (I won't waste space pasting it here, I'm sure you know what it looks like) and the message "Missing soapUI project file.." If I try it without the -m option, it works fine. I've tried various combinations as well, -m0, which gives me an "Unrecognized option" error, and -m 1, which also just prints out the usage. I've tried just -m by itself, not really expecting it to work, and indeed, it fails with a "NumberFormatException". It's not really critical or anything. I just don't use the exported failures because they make much more sense within the context of the full log, so I just delete them. Thought it would be nice if I could tell testrunner to omit them to begin with. Thanks!1.6KViews0likes2Comments