In professional use RF keyword based test ”language” is clumsy. Why not use Python as the programming language and then RF as kind of support library. ( Reports etc.)
If you are fine writing the top level test description in Robot side, you can implement all your keywords in Python. To be able to write everything in Python and still get same logs and reports Robot generates would require either new APIs to Robot or some new tool that can generate output.xml file that’s compatible with Robot. Using PyTest would be a food option as well
How clumsy Robot’s language feels apparently depends on the person. In the recent RF 5.0 survey users especially wanted more programmatic features like TRY/EXCEPT and WHILE when they would have all these features available if they’d implement all keywords in Python:
1 Like
Robot Framework is just a tool (framework etc). If your engineers write clumsy Robot Framework code then believe me their Python code will be even worse 
I find RF useful if I want to have separate layer in automation, where I can easily replace implementation without changing test cases. RF is also nice to combine various type od tests
2 Likes
I personally put most logic in Python since Python is a very powerful and productive language for that.
To write test cases however, Python (and, in my opinion, every regular programming language) is a terrible choice. In a test case you want to express functional steps. Anything that’s not natural language detracts from that.
For keywords, it entirely depends on the specifics if I put it in RF syntax or as a Python method. If the keyword is a number of functional steps that are other keywords, it’s much less writing and much more readable in RF syntax than in Python. If there’s more than trivial logic involved, I’ll implement the keyword in Python.
So in a way, I use RF mostly as a runner framework that takes care of routing (CLI provided) variables and outputs usable logging (most commonly used frameworks are really unit test frameworks with logging and reporting that’s ill suited for functional testing). I can write test cases that are highly readable (anyone with no Python or RF syntax knowledge can understand them) and there’s very solid options for running them (selection by file, folder, include and exclude by tags, adding and removing test cases by using pre-run and Listeners, etc.), options that most (unit test) frameworks are lacking.
So, in my opinion, it’d be silly to call RF functionality from within, say, a pytest run; you would already have opted for less flexible in variable handling, less flexibility in test case selection and forcing yourself to write less readable test cases due to required boiler plate code.
3 Likes