HeikoStudt
Occasional Contributor
Joined 10 years ago
User Profile
User Widgets
Contributions
Opening seperate windows for SoapUI/ServiceV
Changing the "applications" SoapUI and ServiceV using the tabs is completely inconvenient, as you often switch from one to the other for testing your own mock whether the latter works as expected. If you switch back to the ServiceV tab, the view is in an initial view, so that you have to search&click through to your script/edit textboxes. It solves the main problem and creates a nice experience if one could open all those "application tabs" in several separate windows (on your second/third/... monitors).1KViews0likes0CommentsRe: Testrunner, Script and "isCommandLine"
By the same bug, the -enableGUI parameter and whatever initGCTImer() does is broken as well. (see below). For the real SoapUI developers: It will fixes plenty of bugs in the Commandline-Testrunner if you fix this issue. Thank you! :-) The problem lies in the AnalyticsHelper: private static boolean analyticsDisabled() { Settings settings = SoapUI.getSettings(); which in turn creates a "DefaultSoapUICore" as there was none initialized before which in turn sets isCommandLine to false. As the AnalyticsHelper opens some GUI component if you did not enable/disable the analytics before, this is already a bug. However - without analytics - in AbstractSoapUIRunner.run() the isCommandLine field is set twice. public final boolean run() throws Exception { if (SoapUI.getSoapUICore() == null) { SoapUI.setSoapUICore(createSoapUICore(), true); SoapUI.initGCTimer(); } createSoapUICore() creates the DefaultSoapUICore which will set isCommandLine to false. setSoapUICore is resetting to true just afterwards... In my uninformed opinion the bug was inserted as the analytics were put inside. As I hate those analytics anyway, I will disable it in my source permamently... :-) 11:01:35,949 INFO [log] isCommandLine:true 11:01:35,951 INFO [log] isStandalone:false Voilà! :-) MFG Heiko Studt2.2KViews1like0CommentsTestrunner: First MockResponseTestStep fails probably if there was no other mock call before.
Preface: As stupid as I am, I filed a bug in the very old sourceforge SoapUI-Project: ;-) There are further bugs/requests entered - probably SmartBear should close that project and/or get over those bug filings... https://sourceforge.net/p/soapui/bugs/692/ We try to start automatic testrunner with some MockResponse TestStep. After migrating to SSL we've got the following exception: java.lang.NullPointerException at com.eviware.soapui.impl.wsdl.submit.AbstractMessageExchange.<init>(AbstractMessageExchange.java:33) at com.eviware.soapui.impl.wsdl.submit.AbstractWsdlMessageExchange.<init>(AbstractWsdlMessageExchange.java:36) at com.eviware.soapui.impl.wsdl.panels.mockoperation.WsdlMockResultMessageExchange.<init>(WsdlMockResultMessageExchange.java:43) at com.eviware.soapui.impl.wsdl.teststeps.WsdlMockResponseTestStep$AssertedWsdlMockResultMessageExchange.<init>(WsdlMockResponseTestStep.java:1064) at com.eviware.soapui.impl.wsdl.teststeps.WsdlMockResponseTestStep.internalRun(WsdlMockResponseTestStep.java:407) at com.eviware.soapui.impl.wsdl.teststeps.WsdlMockResponseTestStep.run(WsdlMockResponseTestStep.java:354) at com.eviware.soapui.impl.wsdl.support.AbstractTestCaseRunner.runTestStep(AbstractTestCaseRunner.java:211) at com.eviware.soapui.impl.wsdl.testcase.WsdlTestCaseRunner.runCurrentTestStep(WsdlTestCaseRunner.java:47) at com.eviware.soapui.impl.wsdl.support.AbstractTestCaseRunner.internalRun(AbstractTestCaseRunner.java:138) at com.eviware.soapui.impl.wsdl.support.AbstractTestCaseRunner.internalRun(AbstractTestCaseRunner.java:46) at com.eviware.soapui.impl.wsdl.support.AbstractTestRunner.run(AbstractTestRunner.java:129) at com.eviware.soapui.impl.wsdl.support.AbstractTestRunner.start(AbstractTestRunner.java:77) at com.eviware.soapui.impl.wsdl.testcase.WsdlTestCase.run(WsdlTestCase.java:595) at com.eviware.soapui.tools.SoapUITestCaseRunner.runTestCase(SoapUITestCaseRunner.java:565) at com.eviware.soapui.tools.SoapUITestCaseRunner.runRunner(SoapUITestCaseRunner.java:397) at com.eviware.soapui.tools.AbstractSoapUIRunner.run(AbstractSoapUIRunner.java:204) at com.eviware.soapui.tools.AbstractSoapUIRunner.run(AbstractSoapUIRunner.java:139) at com.eviware.soapui.tools.AbstractSoapUIRunner.runFromCommandLine(AbstractSoapUIRunner.java:114) at com.eviware.soapui.tools.SoapUITestCaseRunner.main(SoapUITestCaseRunner.java:120) Following the installed code (5.2.x) and a derieved eclipse project (is there any ready-to-compile out there?) the error seems to be in: com.eviware.soapui.impl.wsdl.teststeps.WsdlMockResponseTestStep.internalRun(WsdlMockResponseTestStep.java:407) where the messageExchange is created even for a null getLastResult(). At the end, in the inheritance hierachy, this is not valid. The following patch fixes the error above. However, I cannot estimate all the consequences. AssertedWsdlMockResultMessageExchange messageExchange = new AssertedWsdlMockResultMessageExchange( mockRunListener.getLastResult()); result.setMessageExchange(messageExchange); if (mockRunListener.getLastResult() != null) { lastResult = lastResultTemp; mockResponse.setMockResult(lastResult); context.setProperty(AssertedXPathsContainer.ASSERTEDXPATHSCONTAINER_PROPERTY, messageExchange); assertResult(lastResult, context); } into WsdlMockResult lastResultTemp = mockRunListener.getLastResult(); if (lastResultTemp != null) { AssertedWsdlMockResultMessageExchange messageExchange = new AssertedWsdlMockResultMessageExchange( lastResultTemp); result.setMessageExchange(messageExchange); lastResult = lastResultTemp; mockResponse.setMockResult(lastResult); context.setProperty(AssertedXPathsContainer.ASSERTEDXPATHSCONTAINER_PROPERTY, messageExchange); assertResult(lastResult, context); } else { result.setMessageExchange(null); //TODO: Really? } MFG Heiko Studt962Views0likes0CommentsRe: Need to get dynamically set project variables from command line
How about using "-S" for save the project? Be carefull, though, as it might collide with your running SoapUI GUI or your source control. A second option might be an "startup" groovy script for calling a "init" testcase in all the others and then go further. IMHO this might work... MFG Heiko Studt1.7KViews0likes0CommentsRe: How to control MockResponse added as a TestStep
You can set "Start Step" in MockResponse Properties. This should be RequestA. This will start the mock before RequestA ist sent. If you want to go sure, add a delay-teststep of 10 ms and set this as "Start Step". :-) BTW: You should setup a Timeout for a MockResponse as well, especially for Continuous Integration as your service may have a bug... MFG Heiko Studt797Views0likes1CommentRe: Testrunner, Script and "isCommandLine"
kondasamy wrote: So, just to make your code work, you could probably try the below script using 'isStandalone' instead of 'isCommandLine' like this, And I guess the behavior of 'isCommandLine' currently you are experiencing should be a bug! Yes, the workaround with isStandalone is working in my project. I absolutely agree, that the isCommandLine has to be corrected, as ATM all manual steps will fail in testrunner.bat. Can someone please point me to the bug tracking system of SoapUI? A quick google search did not find one. MFG (Best regards) Heiko Studt2.4KViews0likes2CommentsRe: Testrunner, Script and "isCommandLine"
The "isStandalone" seem to be false for TestRunner and true for SoapUI (GUI). However, I did not read the source code for understanding what "isStandalone" should mean, there are no comments whatsoever. MFG (Best regards) Heiko Studt2.4KViews0likes4CommentsRe: Prefix a property transfer in header
Hi, I am rather not a professional SoapUI user yet... however, for me it is less complex in understanding the solution in two steps: Use a property transfer to extract the value into some TestCase property (or somewhere else) and then in the following TestStep some Property Expansion to prefix the "Bearer" string. MFG (Best regards) Heiko Studt9.6KViews1like0Comments