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!Properties 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'. Thisstepmust 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?Ramping up your usage of SOAP UI NG ? Check out our Free weekly Training webinar!
Hello all, Have you recently bought new Ready! API licenses and are about to kick start your API tests? Register here for our Free Weekly interactive Webinar, Next one is on the 7th of September( day after Labor day) What to expect? Advice on getting up and running on your SOAP and REST projects Hidden gems within the tool that you may not uncover on your own Personalized question-and-answer with our API experts If you have 10+ users and would like to get your users on-boarded, please reply to this message and I'll be in touch. Cheers, Katleen B Snr. Customer Success Advisor EMEA kbb(at)smartbear.com
Invalid User Name and/or Password
Hello After upgrading to 3.47 I was receiving an authorization error message, so I uninstalled 3.47 and went back to 3.44. Now 3.44 is receiving the same error message. So I upgraded to 3.49 and am still seeing the same error. I am just wondering if anyone knows of or has a configuration solution that I can use. I am a functional person running the SOAP UI request to test the response values received. I am logging into Smart Bear as myself and use test users to access the test environment. This was working fine until 3.47 and now it seems 3.44 is now broken and even 3.49. I have no idea of what to look for to figure out what the issue is. Other workmates can access the test environment using the SOAP UI tools they have installed on their laptops and the same test users I am attempting to use. <faultcode>SOAP-ENV:Client.authenticationError</faultcode> <faultstring>invalid username or password</faultstring>
Add a Regular Expression pattern to a String Generator
Current state Currently, the String generator allows to specify the length of the string and the string contents by character categories: Letters–By default, this check box is selected. Digits–By default, this check box is selected. Spaces–By default, this check box is selected. Punctuation marks–By default, this check box is selected. The docs are here https://support.smartbear.com/readyapi/docs/testing/data-driven/types/generator/string.html. Proposal However, there are cases which need more precise string format. Regular expression would allow an elegant way to define the format. I suggest to add an option to set a regular expression pattern. The String generator would follow the regex pattern instead of string length and the above mentioned character categories.
