So have macros using deprecated code (it was working fine). With v5.5.7, it finally broke. So just an FYI for anyone else using deprecated code, this won’t work anymore.
if_v1_deprecated "${!COL5}" != "Create"
do something here
endif_deprecated
It will still go into do something here even if COL5 = Create. The quotes on the left side of the equation is causing the issue, not exactly the deprecated command. But I think the quotes on the left was necessary with the deprecated command (or a much earlier version). A simple update fixed it for me.
if_v2 ${!COL5} != "Create"
do something here
end
@admin, not sure if you want to address this is a bug. If only to be consistent with this from the What’s New.
Removed: Deprecated commands removed from the command drop down. But the commands itself continue to work just as beforee. And you can still edit and add these commands in the source code view tab.
But I think anyone still using code as old as the one I still have should be updating anyway.
As always, thanks for new features. And more importantly, it’s been overall very stable for us the past few months (that’s why deprecated code got left behind).
I had a check for 0 in some field, and appeared to be the code related to this check stopped executing.
Appeared to be, that this gotoif_v1_deprecated command doesn’t check correctly after latest updates. BTW that wasn’t me who made it into brackets, it was auto-refresh during some update, i guess.
How to fix: for me worked to switch to gotoif_v2 and remove brackets. Same worked for if_v1_deprecated -> if_v2.
From one side that was an unexpected surprise to see my test tells me it’s OK while it was actually not. On the other side - time to review cases has come. I assume if that would be more explicitly told to users (that they should recheck cases and update faulty places) - that would be very kind.
Thanks for the useful report! We did not expect if_v1 to fail with this update, that is why there was no warning. In hindsight the issue was that if_v1 and all other _v1 commands were no longer in our QA test suite, so this regression bug remained unnoticed.
That’s reasonable. But everywhere in docs and forum written that old commands will still work as they were and that sounds like no need to change. At first they were working, and new commands were not the same, so to keep working one should have changed logic of testcase and not just command. But now i see i should follow your way.
This works, i agree. It’s not the easyest way, but works. I avoid duplicating cases. Less cases - easier to support. I re-use 1 case if that is possible. In this idea there are two ways to implement: old-style scenarios (more comfortable for me now) and testcases-as-suites that contain only “run” command with calls to other testcases. This also works, but a bit less convenient. Check my replies in this topic for details: other topic
