Contributions
SoapUI testrunner ERROR com.eviware.soapui.SoapUI - An error occurred [Unrecognized option: -F]
I am configuring my testrunner command line per the instructions in https://www.soapui.org/test-automation/running-from-command-line/functional-tests.html I'm getting an error. Is the page linked above correct for SoapUI 5.5.0 testrunner? Note: I have tried with and without a space between the option "-F" and the style "XML", i.e.: -F XML -FXML How can I fix this? /usr/platform/SoapUI-5.5.0/bin/testrunner.sh -I -j -f output -F XML -a -Gnode1=linuxhost1 -Gnode2=linuxhost2 -s 'Smoke Test Launch TestSuite' 5010-837-Smoke-Test-Project-soapui-project.xml ================================ = = SOAPUI_HOME = /usr/platform/SoapUI-5.5.0 = ================================ SoapUI 5.5.0 TestCase Runner 2020-04-17 13:03:13,770 [main] ERROR com.eviware.soapui.tools.SoapUITestCaseRunner - org.apache.commons.cli.UnrecognizedOptionException: Unrecognized option: -F 2020-04-17 13:03:13,771 [main] ERROR com.eviware.soapui.SoapUI - An error occurred [Unrecognized option: -F], see error log for details 2020-04-17 13:03:13,771 [main] ERROR soapui.errorlog - org.apache.commons.cli.UnrecognizedOptionException: Unrecognized option: -F org.apache.commons.cli.UnrecognizedOptionException: Unrecognized option: -F at org.apache.commons.cli.Parser.processOption(Parser.java:363) at org.apache.commons.cli.Parser.parse(Parser.java:199) at org.apache.commons.cli.Parser.parse(Parser.java:85) at com.eviware.soapui.tools.AbstractSoapUIRunner.initFromCommandLine(AbstractSoapUIRunner.java:151) at com.eviware.soapui.tools.AbstractSoapUIRunner.validateCommandLineArgument(AbstractSoapUIRunner.java:120) at com.eviware.soapui.tools.AbstractSoapUIRunner.runFromCommandLine(AbstractSoapUIRunner.java:111) at com.eviware.soapui.tools.SoapUITestCaseRunner.main(SoapUITestCaseRunner.java:122) org.apache.commons.cli.UnrecognizedOptionException: Unrecognized option: -F at org.apache.commons.cli.Parser.processOption(Parser.java:363) at org.apache.commons.cli.Parser.parse(Parser.java:199) at org.apache.commons.cli.Parser.parse(Parser.java:85) at com.eviware.soapui.tools.AbstractSoapUIRunner.initFromCommandLine(AbstractSoapUIRunner.java:151) at com.eviware.soapui.tools.AbstractSoapUIRunner.validateCommandLineArgument(AbstractSoapUIRunner.java:120) at com.eviware.soapui.tools.AbstractSoapUIRunner.runFromCommandLine(AbstractSoapUIRunner.java:111) at com.eviware.soapui.tools.SoapUITestCaseRunner.main(SoapUITestCaseRunner.java:122)1.4KViews0likes1CommentWarnings "since there is no valid repository"
Since my upgrade to ReadyAPI 2.3.0, I'm seeing warnings in the ReadyAPI log like these for everytest case in my project: Fri May 11 11:59:56 PDT 2018:WARN:The test run data of the test case 'Test Case 001' will not be stored, since there is no valid repository. Fri May 11 11:59:56 PDT 2018:WARN:The test step run data (information about the latest runs) of the test case 'Test Case 001' will not be stored, since there is no valid repository. What valid repository is it looking for? When I run the same project with ReadyAPI 2.2.0 or 2.1.0, these warnings do not occur.Solved2.6KViews0likes5CommentsRe: "Resource Root" property ${projectDir} and relative path
I know this is old, but I see no answers. Since I cannot find my answer, I'll probably have to formulate a new question, but I wanted to point out to the last commenter, nmrao, that ${projectDir} is mentioned in the ReadyAPI documentation... here's a link to one page I found today: https://support.smartbear.com/readyapi/docs/configure/workspaces/properties.html excerpt: To use the file path relative tothe project directory, use${projectDir}\data. For example: D:\projects\webservice\data\testdata.xls To use the file path relative tothe directory that contains the workspace file, use${workspaceDir}\data. For example: D:\projects\data\testdata.xls7 years agoPlace ReadyAPI QuestionsReadyAPI Questions7KViews0likes1CommentIn a SoapUI NG response viewer, XML format, what does Alt-V Validate?
In SoapUI NG Pro, when looking at a response in the XML viewer, the right-click context menu shows a "Validate" option, with a keyboard alternative of Alt-V. What does this do? After some time searching and browsing the online documentation, I found some documentation of theXML Response panel, but there is no description of theright-click context menu popup or the functions these expose. I'm especially interested in where SoapUI is getting the information to report that it expected before the end of the content an element which is not present. The validation message is of the form: line 5: Expected element 'sampleElement@http://sample.name.space.com/SampleServiceResponseType' before the end of the content7 years agoPlace ReadyAPI QuestionsReadyAPI Questions1.1KViews0likes2CommentsRe: How do I test for non-existence of an XML element while avoiding error: Unexpected element: CDATA
I'm sorry that my plea for assistance is so unhelpful. This kind of reaction is why I seldom post to community forums. I already feel like an idiot because I can't figure it out on my own. If a community hero cannot understand me, maybe I should keep away. I want a groovy solution. Rather than the response, I thinkyou want to see my request XML. The scripts I have arechecking the request for existence of an XML element, which in my example I namednonExistentElement, then doing different validations on the response based on what answer comes back about how the request was formulated. The construct as I present in my sample code appears many times in many different scripts, and they are all generating errors which I would like to clean up. Whether I use the context expansion with an exact XPath, or one with wildcards as I have given, when the element is not there, I get a null back, which is all fine and good for the working of the script conditional branching; however, I also get an annoying error in the error logs and the Ready API logs about "Unexpected element: CDATA". I want to eliminate the error by some means. I would like some way to evaluate in the groovy script whether an Xpath exists or not, but without generating an error in the case where the Xpathdoes not exist.7 years agoPlace ReadyAPI QuestionsReadyAPI Questions4.6KViews0likes8CommentsHow do I test for non-existence of an XML element while avoiding error: Unexpected element: CDATA
// The following sample is based on advice given on SmartBear community about how to check for the non-existence of an xml element // https://community.smartbear.com/t5/SoapUI-Open-Source/How-to-check-non-existence-of-a-xml-element/m-p/37511/highlight/true#M15180 def testStepName = context.testCase.getTestStepAt(context.getCurrentStepIndex()).getLabel() def expectNull = context.expand( '${'+testStepName+'#Request//*:nonExistentField}' ) assert expectNull.isEmpty() // The assertion works as expected; however, thecode generates an error when expanding the Xpath // ERROR:An error occurred [error: Unexpected element: CDATA], see error log for details // How do I test for non-existence of an XML node without generating an ERROR in SoapUI?7 years agoPlace ReadyAPI QuestionsReadyAPI Questions5KViews0likes12CommentsRe: Unexpected diffs: Automatic update of element id attributes in SoapUI obscures intentional changes
I have solved this. The tests that were exhibiting the constant refresh of element id had testCase or testSuite name value identical to another test. This apparently did not confuse SoapUI 4.6.4, but when importing into Ready-API 1.8.5, it confused it enough to mess up the project save, although no error message was detected. How did the test cases and suites get duplicate name? The UI (even SoapUI 4.6.4) won't let you enter a duplicate name. I speculate that this may have occurred when merging project edits, or by some hotshot who copied an existing test case or test suite folder with the intent of modifying it, but did not catch all the places where the namehad to be modified when working outside the UI. The fix was to edit the xml files to makethe conflicting name elements were unique, then re-import the project into Ready-API. Now, when I make a change using the UI, only files related to that change show differences, and the differences look like the changeI intended to make. Hooray!8 years agoPlace ReadyAPI QuestionsReadyAPI Questions1.1KViews0likes0CommentsUnexpected diffs: Automatic update of element id attributes in SoapUI obscures intentional changes
Is there a way to limit the automatic update of element identifier attributes so that they do not obscure intentional changes in a diff of the project files? We are upgrading from SoapUI Pro 4.6.4 to SoapUI NG Pro 6.0.0 (in Ready!API 1.8.5). We keep our SoapUI projects under source control (in a GIT repository). I notice that when I open a SoapUI project in the new version, it adds an ID attribute for every element. I see a note on the team testing support page that this is new since SoapUI 5.1, along with some added credentials elements as well as folder structure changes for composite projects. (https://www.soapui.org/soapui-projects/team-testing-support.html) I expected that once I opened the project and saved it with the new structure and element identifier attributes that subsequent commit of changes would be limited to the elements I actually changed. But it appears that some and sometimes many of the ID attribute values get updated with a new generated GUID every time I open and save, whether or not I have made any other changes! This is bad for tracking changes. Based on other things I have read, totry to limit this, I have tried the following: - In Preferences->WSDL, check "Pretty print project files" This seems to help with general formatting differences, but I'm still getting diffs in the GUID of elements I have not changed. How to reproduce: 1. Launch Ready! API 1.8.5 2. Select "SoapUI NG Pro" 3. Import a composite project built with SoapUI 4.6.4 4. Save; Close Ready! API; commit or copy the project file structure on disk for future reference 5. Launch Ready! API 1.8.5 6. Select "SoapUI NG Pro" 7. File->Save All Projects 8. Diff the project folders (I use Beyond Compare) I would accept minimal differences such as a timestamp of the last session. But I see multiple updates of ID's for various elements of some tests. For example, line 7 of one test file has changed over three different sessions. In one it looks like: <con:testStep type="groovy" name="DataExtractor" id="9e0d1ed7-9762-4dc0-8caa-13bde9d9139e"> On next save of the project, the line changed to: <con:testStep type="groovy" name="DataExtractor" id="86478262-d8d5-4ff5-ac4a-5663df67b9fd"> On a third viewing itchanged to <con:testStep type="groovy" name="DataExtractor" id="f5a3cb98-f8de-42a2-82ca-32dac6637612"> This same test file has consistently had 22 of these kinds of updates today every time I save the project, even without making changes.Solved8 years agoPlace ReadyAPI QuestionsReadyAPI Questions1.2KViews0likes1CommentWhere can I download the SoapUI tutorials separate from the installer?
I am using SoapUI Pro 4.6.4 on Windows 7 Enterprise. I do not have access permission to run an installer, and the IT department did not install the tutorials. Is there somewhere I can download the related tutorials and sample projects separately?Solved1.3KViews0likes1Comment