Randomly generated values in requests and other ReadyAPI functions
Current situation ReadyAPI DataGenerator provides different random values (random integer, email, name, city, etc.) I like this function since it creates nice test data. However, the random values are only accessible via DataGenerator DataSource. Proposal It would be great if we could use them in: REST, SOAP, and other requests Variable setup Groovy scripts etc. In ReadyAPI the random values could be available via: expansion e.g. ${#Random#FirstName} Get data function adding a Random category in the top level Implementation proposal Wrapping Java Faker (https://github.com/DiUS/java-faker ) would do the task. Java faker can be configured to use localized data (e.g. english names, spanish names, etc.) The faker provides a lot of interesting data useful for testing, just to name few of them: Address Animal App Artist Avatar Aviation Book Business Company Color File Finance Food Name Nation Number PhoneNumber and many more, including some funny categories like ChuckNorris.
Re-insert the Assertion HTTP
in version 3.9.0 there is a smartAssertion created that deprecates the HTTP assertions. As all of my testcases (a huge amount) have this assertion I'm not going to adapt them manually as this will take a huge effort to do so. No clue why Smartbear has deleted this assertion as I think quasi all of the testers are using this!? Please, re-install the HTTP assertions!
SoapUI-5.7.0 OpenJDK 16.0.2 Vulnerability / Update
Hello All, I am a system administrator and my development team is using the latest SoupUI-5.7.0 and its getting flagged in our vulnerability analysis system as needing to update "OpenJDK to a version greater than 7u311 / 8u302 / 11.0.12 / 13.0.8 / 15.0.4 / 16.0.2" showing that the current installed version is 16.0.1 2021-04-20. Can I update OpenJDK without compromising SoapUI-5.7.0 and or is there an update for SoapUI that will address this issue in the future? If so, can where can I find the information on that or the timeline so that I can monitor for its release?SoapUI long term issues
Hi, I have been using SoapUI for a while with a view to recommending it and ReadyAPI to the company as our default SOAP and REST api tool. However there are some fundamental problems that seem to have been around on the forums for a while that I would like further information on if possible. By the way I am using version 5.7.0: WSDL refresh - SoapUI often gets itself into a state where a service Update Definition will always fail with a message that includes the phrase "a[c] is null". Saving the project, closing SoapUI, restarting SoapUI and performing another Update Definition will be successful. Adding requests to operations - Often either adding a new request or cloning an existing rest on an operation will create the request, but it never appears in the tree beneath the operation and there is no way to refresh the tree. The only way I have found to select the new request is to select the same operation in the mock service and right-click Open Request and then choose the new request. The only way to see the request under the operation is to once again saving the project, close SoapUI, and restart SoapUI. Mock service caching - I have also had a few occasions where a mock service will return old responses rather than an updated one, as if it were cached. This is infrequent and harder to reproduce consistently, but stopping the mock service and restarting it makes no difference, and again only saving the project, closing SoapUI, restarting SoapUI, restarting the mock service and make the request again will get the expected response. Documentation - The online documentation is quite light. I found this to be particularly true for mock service operation dispatching, where a few more examples would help, and a full API for the build in objects such as requestContext. Also a link to the APIs for the items that can be imported would be useful. Forum - There doesn't appear to be much forum activity, and I haven't noticed much interaction from SmartBear employees. Cheers, Chris
SOAPUI log4J vulnerability
We upgraded to 5.7 however our scans are still flagging a security issue with LOG4J. I thought 5.7 would have corrected this as the release notes indicate the new jar files are included. I physically checked the server and I do in fact see the log4j-1.2.15 and not the 2.17 versions. Any advice? Path : C:\Program Files\SmartBear\SoapUI-5.7.0\hermesJMS\lib\log4j-1.2.15.jar Installed version : 1.2.15Properties in SoapUI - case study
The possibility to use properties is a very important aspect in SoapUI automation. And although they are widely used they tend to be not very well understood. Indeed the name 'property' seems a little unfit for an element that (by all means) is presented by SmartBear as a variable to hold certain values for later use in the test execution cycle. For instance, one can have a 'sessionId' element to hold the current session string or one can have a 'cookie' element to hold some cookie value and so on. 1. Defining properties Properties can be defined at the project level, at the test suite level, at the test case level or in a special properties step. For instance, in order to define or edit a property at the test case level one must click on the desired test case in the left hand navigator and then just select the 'Custom Properties' tab. This is similar for any test suite or project. As said before there is also the possibility to use a special 'properties step'. This step must be created inside a certain test case thus its properties will only be available inside that particular test case. 2. Reading properties 2.1 Referencing in SoapUI steps When wanting to reference a property, attention has to be paid to the level at which it was defined. There are different syntaxes that need to be written depending on it as presented in the table below: Level at which it is defined Syntax Example property name Example request Project level ${#Project#Property} Port http://myserver:${#Project#Port} Test suite level ${#TestSuite#Property} Port http://myserver:${#TestSuite#Port} Test case level ${#TestCase#Property} Port http://myserver:${#TestCase#Port} Special properties step ${#Property} Port http://myserver:${#Port} Following the above example, if one would have a project level property named Port with the value 8080, then that property could be used anywhere in the project by simply referencing it like ${#Project#Port}. Example: When sending the request, the value of the ${#Project#Port} would be replaced by its value (in our example 8080). 2.2 Referencing in scripts In order to read a property in a script the following syntax is required: /** * Notes: * There are 4 properties defined at 4 levels: project, test suite, test case and special properties step level * The special properties step is simply called 'Properties' */ def stepProperty = testRunner.testCase.getTestStepByName( "Properties" ).getPropertyValue( "myCustomProperty" ) def testCaseProperty = testRunner.testCase.getPropertyValue( "myCustomProperty" ) def testSuiteProperty = testRunner.testCase.testSuite.getPropertyValue( "myCustomProperty" ) def projectProperty = testRunner.testCase.testSuite.project.getPropertyValue( "myCustomProperty" ) 3. Updating properties Updating tests can be done using a groovy script or a special transfer property step. Both of the methods are simple and straightforward but for the purpuse of this article only a groovy script example will be shown: /** * Notes: * This script changes 4 properties defined at 4 levels: project, test suite, test case and special properties step level * The special properties step is simply called 'Properties' */ testRunner.testCase.getTestStepByName( "Properties" ).setPropertyValue( "myCustomProperty", "newSpecialValue" ) testRunner.testCase.setPropertyValue( "myCustomProperty", "newTestCaseValue" ) testRunner.testCase.testSuite.setPropertyValue( "myCustomProperty", "newTestSuiteValue" ) testRunner.testCase.testSuite.project.setPropertyValue( "myCustomProperty", "newProjectValue" )Delete multiple selected request headers at once [BUG?]
Current behaviour: 1) In the additional request headers tab of a SOAP/REST test step I select multiple headers (the selected headers visually are selected by having the color blue = OK). 2) I click on the delete bin button. 3) Only the first header is deleted. Expected behaviour: ALL of the selected headers should be deleted. If a use wants to delete 10 headers he now has to manually select them and delete them one-by-one. This is frustrating. Note: this issue has been around for ages. Additionally: We (luckily) can select and copy the headers properly by doing a select and then Ctrl+C. The feature of copy-pasting request headers might not be really visible in the UI (e.g. there is no "copy" button), but I am very grateful this is possible through Ctrl+C. Might be wise to visually allow this to?
soapUI 5.6.0. java.lang.NoSuchMethodError with Java12
Hi, sind last week we used soapUI 5.4. with Java8 Now we made a update to soapUI 5.6.0. After installation of Java12 AdoptOpenJdK soapUI writes an error: [exec] SoapUI 5.6.0 TestCase Runner [exec] Configuring log4j from [/usr/gasx/R00/jenkins/dev-tools/soapui-5.6.0_20200715/bin/soapui-log4j.xml] [exec] 12:54:18,641 INFO [SoapUI] Adding [/usr/gasx/R00/jenkins/dev-tools/soapui-5.6.0_20200715/bin/ext/mariadb-java-client-2.6.1.jar] to extensions classpath [exec] 12:54:18,642 INFO [SoapUI] Adding [/usr/gasx/R00/jenkins/dev-tools/soapui-5.6.0_20200715/bin/ext/ojdbc6.jar] to extensions classpath [exec] Exception in thread "main" java.lang.NoSuchMethodError: org.apache.xmlbeans.XmlOptionsBean.isLoadDTDGrammar()Z [exec] at org.apache.xmlbeans.impl.common.SAXHelper.saxFactory(SAXHelper.java:70) [exec] at org.apache.xmlbeans.impl.common.SAXHelper.newXMLReader(SAXHelper.java:46) [exec] at org.apache.xmlbeans.impl.store.Locale.getSaxLoader(Locale.java:3073) [exec] at org.apache.xmlbeans.impl.store.Locale.parseToXmlObject(Locale.java:1272) [exec] at org.apache.xmlbeans.impl.store.Locale.parseToXmlObject(Locale.java:1259) [exec] at org.apache.xmlbeans.impl.schema.SchemaTypeLoaderBase.parse(SchemaTypeLoaderBase.java:345) [exec] at org.apache.xmlbeans.impl.schema.SchemaTypeLoaderBase.parse(SchemaTypeLoaderBase.java:252) [exec] at com.eviware.soapui.config.SoapuiSettingsDocumentConfig$Factory.parse(SoapuiSettingsDocumentConfig.java:59) [exec] at com.eviware.soapui.DefaultSoapUICore.initSettings(DefaultSoapUICore.java:259) [exec] at com.eviware.soapui.DefaultSoapUICore.init(DefaultSoapUICore.java:141) [exec] at com.eviware.soapui.DefaultSoapUICore.<init>(DefaultSoapUICore.java:132) [exec] at com.eviware.soapui.tools.AbstractSoapUIRunner.createSoapUICore(AbstractSoapUIRunner.java:216) [exec] at com.eviware.soapui.tools.AbstractSoapUIRunner.run(AbstractSoapUIRunner.java:192) [exec] at com.eviware.soapui.tools.AbstractSoapUIRunner.run(AbstractSoapUIRunner.java:137) [exec] at com.eviware.soapui.tools.AbstractSoapUIRunner.runFromCommandLine(AbstractSoapUIRunner.java:112) [exec] at com.eviware.soapui.tools.SoapUITestCaseRunner.main(SoapUITestCaseRunner.java:122) SoapUI runs on Redhat 7.8 and openjdk version "12.0.2" 2019-07-16 OpenJDK Runtime Environment AdoptOpenJDK (build 12.0.2+10) OpenJDK 64-Bit Server VM AdoptOpenJDK (build 12.0.2+10, mixed mode, sharing) The Fix in https://community.smartbear.com/t5/SoapUI-Open-Source/Soap-UI-5-6-0-tgz-on-Linux-is-broken-FIX-INSIDE/m-p/204960#M30957 don't work - and I don't know why the normal release of soapUI has this bug. Can you help me? Best Regards from Germany, Michael
