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!
Allow SoapUI assertions to vary depending on selected environment
In cases where API responses vary depending on environment and this is not in control of the QA team it would be useful to be able to specify which environments an assertion applies to. This would allow a test step to have different assertions only a subset of which are evaluated in any given environment.
Smart Assertion Conditions NOT Matches Regex
List of Smart Assertion Conditions 0. <, > , >= , <= 1. Equals AND Not Equal 3. Equals (one of) AND Not Equal (one of) 5. Exists AND Does NOT Exist 7. Empty AND NOT Empty 9. Contains AND does NOT Contain 11. Matches (regex) AND.... AND..... (!!) And... and..... and....!!! Uh..... what happened to NOT MATCHES (regex) ?!?!
Make Smart Assertion more useful with added features
Smart Assertions are very useful when having lots of data that need to be asserted. However currently there are a few issues that make it more difficult then it needs to be: 1. No Search Facility that allows quickly to jump to an item. 2. No conditional flow where assertions can be managed depending on some response details. 3. No facility to deal with lists that are unsorted and can be in a different order each time. 4. No facility to convert the Smart Assertions to Groovy Script which would make it useful as a tool to get a basic script with all the assertions that can be further edited to deal with special cases. Our responses contain hundreds of pieces of data that need to be evaluated. The Smart Assertions are great for quickly generating the assertions of a response but since we have many lists which don't arrive in a specific order, this does not work very well for us. If the Smart Assertions could recognise lists and pre-order them before assertion this would solve this problem and save us a lot of time. We also have an issue with repeated properties like for example version numbers that we only want to change once and then have it used in many places. However using a property only works as long as the data doesn't change. When data changes and we have to make a "Load from Transaction" again, those properties have to be added again. It would be nice to have something like an "Update from Transaction" that notices changes but doesn't overwrite existing items that haven't changed and preserves the properties being used. A differential dialog might be useful here when updating where we can see the changes, modify them if necessary or have them applied. Another great feature would be a conversion from Smart Asserts to Script. Other test applications that we use for desktop applications already can do this and it would be nice if SmartAPI also would be able to generate a script from the Assertions. This would help with situations where we need to have lots of special flows , loops and transformations of data but don't want to always have to write each assert from scratch.
Smart Assertion on GraphQL Request Step
I was wondering why we can make a Smart Assertion on REST requests but can't make a Smart Assertion on GraphQL Request Step. We are currently using REST requests to test GraphQL as suggested and since the Smart Assertion tool is crucial in API testing for us but was wondering if there were any plans to support Smart Assertion in GraphQL requests? Seems like functionality of sending a REST request as a graphQL request is much more feature rich at this point in time.Smart assertion: ONLY populate FAILED assertion from received data
It would be very helpful to have the option to ONLY populate FAILED assertions from received data in the Smart Assertion. Now it's only possible to populate all data, which results in losing, for example, valid values asserted by property data.Adds the possibility to name an assertion when creating it
State of the art When we add an assertion to a Test Step, a default name is given to this newly created assertion. If I want to change its name, I have to clic on it to rename it. Request It would be easier and time saving to be able to rename assertion when modify it or when creating it.
Do not remove property when populating new values in Smart Assertion
When Smart Assertion is created property is used for some values in Valid Value column in Smart Assertion (ReadyAPI v3.9.2). Some values might changed in response so it is nice to use "Populate from Received Data". But it changes all values from response. It would be nice that there would be possibility to save/leave not changed properties.Automatically create testcases/assertions based on swagger definitions
Hi, I believe there should be a feature that uses the Swagger definitions for REST API services much more profoundly. The current "Swagger Compliance Assertion" is not covering this. It's too broad and generic. I would love to have an option to automatically create the standard edge test cases based upon swagger definitions as that would save a lot of time for readyAPI customers. There is a security JSON boundary scan, but that only verifies that there is no sensitive data in the response. It doesn't doe anything with the provided swagger information. There is also no way to see what exactly the boundary scan does, except for going into the transaction log to see each individual request payload (https://support.smartbear.com/readyapi/docs/security/scans/types/boundary-json.html) Suggestion: Button to "Create negative tests from Swagger": - Example1: Automatically a test cases is created with a REST test step where JSON payload or request parameter is set to whatever minLength / maxLength is defined in the swagger. If for instance maxLength is 99 I want ReadyAPI to have a value set to 100 character length. Expected outcome would then be an HTTP400 (customizable with a predefined response payload check). - Example2: Automatically test cases are created where we omit the "required" fields (be that headers, request payload parameters or query parameters). So either it's set to null or it is completely missing from the request. Again expectation would be an HTTP400 or HTTP401/403 for authorization headers.
