0

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.

koxta
  • 846
  • 2
  • 8
  • 30

3 Answers3

3

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.

A. Kootstra
  • 6,827
  • 3
  • 20
  • 43
3

First off, there is no "best". What is best for one organization or team won't be best for another. How many do you have? How often do they change? How much are they re-used between pages or between applications? Do you use them in your tests, or only in keywords? Are most of your keywords written in robot syntax, or in python or some other programming language?

Personally I'm a pretty big believer in not storing or managing locators for the project as a whole. I do not think tests should have locators in them at all.

I am of the opinion that robot framework works best when you use it as a framework, by creating your own custom keywords. The locators only need to be visible to the keyword or keywords that use them, rather than sprinkled throughout your code.

I'm a strong proponent of using the page object pattern, where each page or each section of a page is represented as an object. Within that object you only need the locators for the elements in that page or section of a page. In my experience that usually means just a very few locators per page.

For an example of how to implement page objects with robot, see my open source project, robotframework-pageobjectlibrary. This implementation has a data structure for storing locators, but over the past year I've found myself rarely using that, opting instead to hard-code the locators in each function.

Bryan Oakley
  • 370,779
  • 53
  • 539
  • 685
  • It's also been my observation that reuse of locator references is low when using a layering approach where the UI functions/features are abstracted in a seperate layer from the actual test logic. When the Id are stable references, I'd hard code them too. – A. Kootstra Dec 06 '17 at 07:56
  • @A.Kootstra: I agree. After switching to using a page object model, I've found that I rarely re-use locators. – Bryan Oakley Dec 06 '17 at 12:46
3

I'm working on a similarly large Robot Framework project at the moment, so I've had to tackle this issue myself. Here's my solution:

.
|-- Project
|   |-- Tests
|   |   |-- Suite1.robot
|   |   |-- Suite2.robot
|   |   |-- ....robot
|   |-- Resources
|   |   |-- Suite1_Resources
|   |   |   |-- Suite1_Keywords.txt
|   |   |   |-- Suite1_Variables.txt
|   |   |-- Suite2_Resources
|   |   |   |-- Suite2_Keywords.txt
|   |   |   |-- Suite2_Variables.txt
|   |   |-- ..._Resources

Details

One suite deals with keywords ranging over the site as a whole (e.g. Check Navigation), while the rest are specific to each individual page. Every Keywords file deals with only the keywords of one specific page on the website. Every Variables file deals with only the variables of its associated page. Every variable name starts with a two-letter ID for the page it's associated with to avoid accidentally inheriting a same-name variable from another page. Keywords files inherit from their associated Variables file and other Keywords files. The .robot tests inherit from multiple Keywords files as required to form the test cases.

Brandon Olson
  • 619
  • 2
  • 6
  • 19