Issues and Feedback about Smart Assertions
Some issues and feedback about Smart Assertions after a day or so of using them. I would like to provide some hopefully helpful feedback on the newly introduced Smart Assertion. Please set the def...
Forum Discussion
The one major issue i have with smart assist is the idea that writing a text trying to inform the user that data will be lost if you swap between the two types is just to me proof that this feature should never have been released in its current state
If it atleast would have been an annoying pop up confirm dialog so you are forced to read that your work will be deleted would be better and then can select cancel/continue
Smart insert simply needs to be split into two asserts one for each tab unless it can be changed so that you can effortless move between the two types without losing data
Metadata and message content assertions should be completely separate assertions because switching the type destroys all the data you have added. How can you modify previously added assertions when all the values are lost? It is the same as not having a modify smart assertion feature at all.
What we have started doing (yes its a "pain point") is to create 2 separate smart assertions, one for "Received Data" and one for "Received Metadata" and then naming them accordingly so users will know which smart assertion to update and / or check if an error is returned.
- Yes, I ended up doing the same 👍
Any update on this Smartbear ? I see no improvements on this in the ReadyAPI v.3.20.0.
I agree with all of the above comments and am equally frustrated by the invisibility of WHAT is tested in the "smart" assertion and the sheer inflexibility. Updating them, for instance when new additional JSON response data is returned, is not possible.
Also, when adding a request from the API section to the testcases via the "add to Test Case" right mouse click menu, the 1 of the default 2 assertions that ReadyAPI by default suggests is the "Valid HTTP Status Codes"... which is in the same ReadyAPI version set as DEPRECATED 🙄. (Side note: In my view these "default assertions" should be open to customization by us. Preferably also based on the swagger info (or other definitions) you used to import the API. For instance, even when it's clearly set in the swagger that a POST request should return a 201 ReadyAPI still suggest 200 😒).
I was more in favor of the above deprecated assertion as at least what assertions are present in my test step without the need for opening the smart assertion. It would be nice to have a quick overview of what is asserted against... In the end, it's the most vital thing of testing: What does your test do? Do I need to add any more checks? I wish I could see this in a glance.
I would not mind that the smart assertion of let's say 4 "Smart Assertion - Metadata" and "7 Smart Assertion - Data" would be translated to 11 individual assertions in the assertions section. Ideally each which the expected and actual value so testers can see what's going on.
