Using effective naming conventions is vital for clear code, teamwork, and debugging. It also plays a crucial role in maintaining automation scripts and frameworks.
This article discusses an approach to naming and folder structure in a UiPath library project with an Object Repository. It provides insights for automation engineers and teams looking to improve their RPA practices.
Let’s analyze the approach used at Flobotics, considering its pros and cons and identifying what to avoid!
Object repository: overview
An Object Repository is a part of a Library project that enables the creation of a set of reusable user interface elements. The Object Repository ensures the management, reusability, and reliability of UI elements by capturing them as objects in a DOM-like repository, shareable across projects. It allows for creating and reusing UI taxonomies inside and across automation projects.
Some key features of the Object Repository include:
- UI elements across the project are managed, updated, and modified from a centralized place
- Drag-and-drop elements from the Object Repository panel
- Objects are reusable in a local project or across projects when packaged as libraries
These key features are why, at Flobotics, we employ the Object Repository as a project practice.
In the next step, we will show the practical implementation of the theoretical assumptions. We will present internal principles, naming conventions, and a specific usage example.
Before we started building the nomenclature standard, we assumed that the application operates in a single web browser. A developer should include this information in the project description. The current approach used in Flobotics follows the naming scheme:
Application -> [Application name]
Example:
NameCRM
Screen -> [Screen name]
Examples:
Login
PPList
Element -> [Element type]_[Element name] (For dynamic selectors, it is recommended to add the prefix “Dyn” to increase readability.)
Examples:
Button_Login
Link_Dyn_SettlementId
Checkbox_PPRow
[OPTIONAL]
Group -> Group_[Group name]
Examples:
Group_MessageBox
Group_Common
A screenshot showing the object repository project
According to the assumption, using the object repository should make work easier. In the chosen naming convention, we prioritize simplicity and clarity. For more complex elements, we suggest adding a description to the element.
Library
A library is a project that contains one or more workflows that can be reused as activities in other projects. Libraries are saved as NUPKG files when published and can be installed as dependencies from the Package Manager.
When creating a library, it’s advisable to follow the same principles we employ for the Object Repository. The names of individual tree elements should be precise and clear. It’s crucial to define and establish the project structure early on, even for complex applications. Changing the workflow name or path affects the project using the library.
Business naming convention
In the diagram below, we have introduced an approach that is consistent with the expectations discussed in the previous chapter. The naming convention is business-oriented:
Folder -> [Application name]_[Screen name]
Example:
NameCRM_Login
Workflow -> [Screen name]_[Action name]
Example:
SettlementList_ClickClearFilter
SettlementList_FillPPNumber
A screenshot showing the library project
Conclusions
Let’s now explore the approach’s pros and cons, which we have drawn from observations and practical use.
