Hello everyone,
I’ve recently joined a new company as a QA lead (first one) and am excited to contribute to the testing efforts.
the company has an established automation layer for API testing using the Robot Framework, created by the company developers.
These tests are quite comprehensive, and I’m keen on preserving their integrity and use their already existing infrastructure they providing while we expand our automation scope.
Now, I’m looking to build upon this foundation by adding an automation layer for web UI and mobile app testing. My goal is to create a robust framework that integrates seamlessly with our existing tests.
However, I must admit that my familiarity with the Robot Framework is limited. The key-driven approach it employs is somewhat new to me, and I’m finding it challenging to envision managing and maintaining a large-scale project with this framework. Moreover, I’ve noticed a scarcity of advanced documentation and tutorials, particularly for designing projects with a broader scope using Robot Framework.
I would greatly appreciate any insights or experiences you could share regarding large-scale projects with Robot Framework, especially those that encompass web and mobile app functionalities.
Tips on project structure, best practices, and resources for advanced learning would be incredibly helpful.
Looking forward to your valuable feedback and suggestions.
Hi,
Robot is not something I’m familiar with but I’ve just done a quick search on our corporate training platform, Udemy. It’s not as obscure as you might think; there’s a good few courses there. You can sign up for free and wait for a flash sale (which are frequent and very cost effective BTW).
In terms of approach, it seems you could simply continue with Robot.
Right at the top of the list in my Udemy search is Robot and Selenium,
Alternatively, if you’re interested in using other tech (e.g. Cucumber or Behave), you may need to be consider strategies to re-use the Robot testing within whatever framework you create.
For web & mobile UI testing, you would want to research a bit and look into the available Robot Framework (RF) libraries that interface/wrap Selenium and Appium, so that you can just call them as keywords to write your robot tests.
For Selenium, there is Selenium2Library, Appium I forget the names, you’d have to search around.
But aside from just which libraries to use, it’s also a matter of how you model your code/tests, etc.
Usually for automation, even with RF, sometimes you do a portion of the logic in code (e.g. python) rather than just the RF “robot” test files. Especially true for complex logic that is harder to handle as just keyword type invocations in the robot test files.
But if you do wish to keep most of the logic as keyword calls in robot files, then here is an example of how you can model the common “page object model” typically used in script/code-based UI tests but here instead as robot files:
Robot can be clean but it can also be chaos. If you dont have strict rules and naming conventions you will get over run with duplicated keywords and cause alot of maintenance havoc.
I have seen Robot work when the test writing team is small but as soon as you get to about 5/6 then the chaos starts and it will probably go two ways. 1 you will be constantly PRing and checking duplication doesnt arise or 2 your keywords will rapidly become unmaintainable and messy.
(This is just my opinion others have had alot of success in robot or just accept situations like this). Good luck with what ever option you decide, my advice would be to create a framework that is suitable for where you want to get to and then write a wrapper to call both the robot framework and your choice of E2E framework.
thanks, guys for the feedback
as you guys suggested, and also in my opinion, RF should be used only for the behavior text test description - which is that it’s doing great work and a better job than most of its alternatives.
I’m going to use it only at the highest level of the test which describes the test behavior and the action them self and the library calls are going to be done only at the code itself.
a decent example can be found here:
it seems there are a LOT of downsides going with a full implementation using only the robot extensions.
See also: