Manage the projectVersion field in "Setting.xml" , so it doesn't update with every save or reload
Reference Issue -https://community.smartbear.com/t5/ReadyAPI-Questions/Ready-API-3-42-0-automatically-updates-projectVersion-every-time/m-p/240988/emcs_t/S2h8ZW1haWx8dG9waWNfc3Vic2NyaXB0aW9ufExBSklETVhHWkdEMTUxfDI0MDk4OHxTVUJTQ1JJUFRJT05TfGhL#M57307 projectVersion value changes everytime a project is saved. When trying to Pull changes from git, setting.xml needs to be committed first, but it re-appears again as a new change, which blocks pulling from git. The "Discard all changes", don't really discard the document.Script library interoperability, javaDoc, refactoring, search & autocomplete in all scripts
I'm sorry, but to me the idea mentioned Intellisense-on-custom-groovy-librarybyrunzTHalmost 6 years ago (wow!) is still not implemented, even though labeled as such. In current version ReadyAPI 3.10.0 I still do not have the kind of intellisense I would like to see: - no hassling with .jar files, I want to have interoperability with all of the groovy files in my custom script library like defined in the ReadyAPI project. A restart of some sort I can understand, but when we need to start with importing files we know this is something that will only work locally and for that version. - PLEASE: Proper IDE capabilities, like auto-complete, auto-formatting, code error detections (missing curly bracket for instance), renaming/refactoring, search (and replace),... in ALL scripts (setup scripts, groovy tests steps, tear downs, script library,...). It is such a breeze when I use other (front-end) test automation tools to see that I can do those things, but then return to ReadyAPI and feel like an IT-guy from the 90's. - I'd like proper javaDoc documentations to know what each method does. Currently I can only see what parameter type(s) I need to provide, but not what this method actually does or what I can expect to be returned. Scripting is such an extra weapon to be used in ReadyAPI, it's a shame it cannot be made more powerful by Smartbear.
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.Add an event for Report post-processing
The need In ReadyAPI there are nice options of reporting, however there is missing any function to do report post-processing. The post-processing needs are: to send a report via email put the report into a storage create a Jira item etc. Currently the report files are just placed in the output directory. On TestCase and TestSuite level there are Report script holders, but the purpose of the script is toextend the reporting options(it is executed before the reports are finished, not after), i.e. for report pre-processing. On the project level there is no such option. Solution proposal A good place to execute specific actions arethe events. But there is no "ReportListener.afterReport" event. Please add a new event ReportListener.afterReport which will be triggered after any report is finished by testrunner. Such event will be used by Groovy scripts to do the report post-processing.
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) ?!?!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?
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.Masking encrypted properties in ReadyAPI Test for Azure DevOps task instead of plain text
Hi, The latest version of ReadyAPI 3.20.0 seems to fix encrypted properties being displayed as plain text in logs within the ReadyAPI software itself but this does not translate when running the project from Azure DevOps using the "ReadyAPI Test for Azure DevOps task" as encrypted properties are still being exposed there. 1. The project password for the task is in plain text - This property should be masked as anyone who views the task would be able to download and access the encrypted project and its properties. 2. Encrypted properties are displayed in the logs/requests as plain text The password has been encrypted in the custom properties using the "selected properties" project encryption . However, encyrpted properties are being shown in the task logs when a request that uses the properties fail or when logged using groovy script as plain text. This display of encrypted properties as plain text is unacceptable especially when creating production tests so it would be benefical if encyrpted properties are not exposed. Thanks, Kayleigh
