tl;dr: what is the future of keywords such as “Should be Equal” , “Should be xyz” in the context of Robot Framework 5 and its successors?
Yesterday, I was having a discussion with a colleague of mine on how to modify code that looks something like this:
${a} = 1
${b} = 2
Should Be Equal ${a} ${b} msg=really long error msg with lots of debug info
My question relates to ‘Should Be’ and his siblings - which only support messaging in case of an error but no action keywords. Based on the RF Python code, all of these keywords are mere assertions which output a message but cannot trigger any further actions.
As I need to enhance my test library with optional push messaging, I can no longer rely on the ‘msg’ option. RF4 supports ‘IF’ constructs which makes it easy to amend my code. Nevertheless, I was wondering if it would make sense to enhance these built-in comparisons so that they can trigger a keyword in case of an error and then let the test fail. e.g.
Should Be Equal ${a} ${b} keyword=Do some magic and then fail the test
which is remotely similary to RF’s try/catch construct. What is the recommended narrative for cases like these and are IF/ELSE going to replace the simple built-in comparisons at a later point in time?
I think we should keep the ‘Should Be’ and his siblings, while an if/else construct is easy for someone like me with a strong programming background, to me one of the strengths of robot framework is that it’s simple to read and simple to write test cases for people with no programming background.
In my view we should be encouraging test automation not putting barriers in the way, robot framework’s current syntax does that in my opinion, I would hate to see robot framework take away ‘Should Be’ and his siblings in favour of the if/else construct as this would take away the beginner friendliness an no programming background needed feature of robot framework.
I agree with Dave on what he wrote, and wish to add this:
Robot Framework is so flexible that allows users to “redefine” or “extend” the keywords. In this case you can just create your own user keyword to execute whatever code you need. For example:
${a} = 1
${b} = 2
Fail If Not Equal ${a} ${b} Do some magic and then fail the test
Fail If Not Equal
[Arguments] ${arg1} | ${arg2} | ${keyword} | ${kwargs}
${result}= Run Keyword And Return Status Should Be Equal ${arg1} ${arg2}
IF "${result}" == "PASS"
Return True
ELSE
Run Keyword ${keyword} @{kwargs}
END
Personally, I second your opinion. Several of the existing ‘Should be …’ keywords encapsulate a lot of logic and offer additional support on stuff like regex validation etc. Retiring these keywords would be unfortunate, especially as there is no real built-in alternative. I am aware that the ‘Run Keyword If’ keywords are no longer supposed to be preferred over regular IF statements and I do wonder if the “Should be” keywords will meet the same fate - hence this forum post.
As a workaround to amending the ‘Should be …’ keywords with additional capabilities, I am likely going to use my existing code blended with the ‘Should be’ keywords. e.g.
${status} = Run Keyword and Ignore Error Should Be Equal ${a} ${b}
Run Keyword If '${status}' == 'FAIL' do some magic and die
This approach retains the existing ‘Should be’ keywords’ functionality while enhancing them (somewhat) with keyword support.
There’s no plans to deprecate Should keywords. Possibly there could be some more generic variation to avoid e.g. then need to use As Integers variants with numbers. Even then I doubt we could deprecate old keywords because they are so widely used.
I also don’t think it’s a good idea to enhance Should keywords so that they’d get a call back keyword to use on failure. RF 5 adds native TRY/EXCEPT functionality which offers a generic solution to such needs.
Hi Peka. Right now I have version 5.1a2 and TRY doesn’t work. To rule out another type of error, is it necessary to download some type of library? Thank you very much and we remain attentive to the solution.