I am building a Robotframework automation project.
As the project grows, it also becomes more difficult to maintain, with the increasing of selectors number in project.
+10K selectors in project (a big one) and almost no changes occur in each one;
Now I have the following structure:
.
|-- Project
| |-- Generic Keywords
| | |-- Web App A
| | | `-- GUI_Actions.robot
| | |-- Web App B
| | | |-- GUI_Actions.robot
| | | |-- DB_Actions.robot
| | | |-- ...
| | `-- ...
| |-- Tests
| | `-- Web App A
| | |-- Suite1.robot
| | |-- Suite2.robot
| | |-- ...
| | `-- Web App B
| | |-- Suite1.robot
| | |-- Suite2.robot
| | |-- ...
What is the best way to keep these locators(separate from the code) in a way that makes the project scalable and maintainable?
- Separated folder "Locators" (in root) with files (resources) and one variable per locator?
- One locators file (one by application) inside "Generic Keywords" and "Web App" folders?
- ... etc
There are many ways to do that, which one is the best?
I appreciate some ideas/suggestions. Thank you.
There will not be a single answer that fits your question as much of it depends on your application, level of technical capabilities and your (organisations) coding style.
If your application's UI is quite repetitive in the form of pages or page parts, with static ID's, then a Page Object model is a good fit. There is a PageObject Library that you can use or take inspiration from.
Another way of centralising your locators is to use a custom locator like
Click Element abc=SomeVirtualId
. An example of this approach can be found in the answer to another SO question. This approach is also useful when the Id's to your elements are predictable and can be generated. Then it centralises the logic without the need for many custom keywords.