Automation

Development and
Testing
Best practices
DEVELOPMENT AND TESTING – BEST PRACTICES....................................................................................................... 1
Naming Conventions .......................................................................................................................................... 3
Configurations .................................................................................................................................................... 3
Credentials .......................................................................................................................................................... 3
Clean Code .......................................................................................................................................................... 3
Source Control .................................................................................................................................................... 3
Workflow Design ................................................................................................................................................. 3
Reusability ........................................................................................................................................................... 3
Error Handling ..................................................................................................................................................... 4
REFramework general rules .............................................................................................................................. 4
Ui Automation ..................................................................................................................................................... 4
Excel ..................................................................................................................................................................... 4
Logging ................................................................................................................................................................ 4
General Rules ...................................................................................................................................................... 4
Development and code review .......................................................................................................................... 5
Test ....................................................................................................................................................................... 5

FOOTER CAN GO HERE 2

Naming Conventions
• Give meaningful names to all components (Workflows, Activities, Arguments and Variables).
• Rename all the activities in a project (including Log Message, Assign, If, Sequence). Do not leave the
default name for activities.
• Use the naming convention for arguments: use in_ / out_ / io_ prefix for identifying the argument type and
the rest should be Camel Case.
• Use the Upper Camel Case naming convention for variables and for workflows
(e.g. FirstName, GetTransactionData.xaml).

Configurations
• Keep environment settings in a config file.
• Use a config file or similar for keeping the settings to allow variations and changes in the input data
without an intervention from a developer, when required.

Credentials
• Robot Credentials are required by the Orchestrator to start an interactive Windows session on an
unattended robot. They are defined in the Orchestrator Robot definitions. The password in stored
encrypted with the 256 bit AES encryption algorithm and once set, the password cannot be displayed.
There's also the possibility of storing the passwords in CyberArk which is integrated with Orchestrator.
• Application credentials should not be stored in the workflows or Config files in plain text, but rather they
should be loaded from safer places such as Orchestrator or Windows Credential Store.

Clean Code
• Keep it clean: close applications, windows, web pages.
• Remove unreferenced variables.
• Remove unnecessary containers.
• Delete the activities and variables that were used for debug.

Source Control
• Use a Version Control System in order to easily manage project versioning and sharing the work on more
developers.
• Collaborate working on separate files.

Workflow Design
• Break the whole process in simple workflows.
• Pick an appropriate layout for each workflow (sequence/flowchart/state machine).
• Typically, workflow files belonging to the same application or system will be grouped together in one
folder under the project root folder. In case there are many files for one application, further categorizing
by using subfolders can be used.

Reusability
• Create workflows that contain small pieces of occurring automations and add them to a library.
• Separate business logic from the automation components will help building a code that can be reused
effectively.
• Common (reusable) components (e.g. App Navigation, Login, Initialization) are better stored and
maintained separately. Is recommended to have a library for every application and the library can contain
both workflows with UI interaction and Object Repository descriptors.

FOOTER CAN GO HERE 3

 • Reuse workflows across projects.

Error Handling
• Avoid using multiple nested try catches, otherwise it makes difficult seeing where the error comes from.
• Make sure the exceptions are used accordingly (e.g. BusinessRuleException vs ApplicationException).
• Avoid placing Click or Type Into activities in Try Catch for UI interaction and use instead synchronization
activities to check the availability of the target elements (e.g. Check App State)

REFramework general rules

• Use REFramework for complex processes.
• Avoid deleting the framework’s pre-defined workflows (if needed, just at the very end of development, you
can delete the invocations of the unused workflows);

Ui Automation

• Avoid using selectors with indexes - try using more attributes or nested selectors.
• Avoid using Delay Activities - Use Check App State activity to verify if the application is in the desired
state.
• Investigate if the application exposes an API that can be used to automate at least a part of the process'
steps. API calls are the most reliable for interaction with an application.
• Avoid using Hardware Events as Input Method, use instead Simulate, Chromium API or
WindowMessages where the application allows.
• Use partial selectors when several activities are executed in the same window.

Excel
• Avoid using Excel files as databases.
• Avoid using Excel Scope and use Workbook activities since they do no require Excel to be installed on
the machine.
• Avoid performing a lot of repeated operations on files as Excel may cause problems such as freezing, not
responding or corruption of file.

Logging
• Using Log Message activities to trace the evolution of a running process is essential for supervising,
diagnosing and debugging a process. Messages should provide all relevant information to accurately
identify a situation, including transaction ID and state.
• Do not log sensitive data (e.g.: accounts, passwords, financial transactions etc.).

General Rules
• Develop and test pieces independently.
• Use annotations for every activity, explaining the purpose of it.
• Use an annotation in the start of a sequence to describe the process handled in the sequence +
prerequisites and arguments.
• Queue items should not store sensitive data.
• No more than 2 nested IF activities, if the logic is more complex, try using a flowchart instead.

FOOTER CAN GO HERE 4

Development and code review

• The Automation Solution Architect is responsible for continuously coaching developers on the best
practices. Hence, frequent and thorough code reviews are a must, to enforce a very high quality of the
developed workflows. This way, the developers are motivated to build robust workflows and to follow the
best practices guide.
• Workflow Analyzer is a powerful tool for both the developer and the SA. The standard rules that come
embedded with the Studio should be up to date for the organization and, if required, new rules can also
be added.
• The developer should run Workflow Analyzer periodically during the development in order to ensure that
the code meets the required standards. In this way, the time necessary for any modifications or feedback
during code review may decrease.
• The SA can use the tool for help during the code review phase, to gather feedback on naming
conventions and best practices used. However, the SA should also have a checklist and should make
sure they look over every workflow and understand the logic. Any improvement should be documented
an implemented at this point, to ensure the high quality of the implementation and also the possibility to
scale the process in the future.

Test
• After each component is built, unit testing should be conducted. If every component is thoroughly tested,
the integration runs more smoothly, and debugging lasts for a shorter period of time.
• There are two methods for unit testing:
o The REFramework contains a Test_Framework folder where all the test files should be placed.
Using the RunAllTests.xaml, a developer can test a sequence containing a lot of xaml files
automatically, thus being able to try out small integrations between components and to run stress
tests. A report is generated at the end of each test. Typically, these kinds of tests should be run
outside office hours, in testing environments, to optimize the developer’s time.
o Using Test Suite and creating Test Sets (group of unit and integration tests) that can be run after
every modification in the code.
• The recommended UiPath architecture includes Dev and Test environments that will allow the processes
to be tested outside the live production systems.
• Sometimes applications look or behave differently between the dev/test and production environments
and extra measures must be taken, sanitizing selectors or even conditional execution of some activities.
• Use config file or Orchestrator assets to switch flags or settings for the current environment. A test mode
parameter (Boolean) could be checked before interacting with live applications. This could be received as
an asset (or argument) input. When it is set to True - during debug and integration testing, it will follow
the test route – not execute the case fully i.e. it will not send notifications, will skip the OK/Save button or
press the Cancel/Close button instead, etc. When set to False, the normal Production mode route will be
followed.
• This will allow you to make modifications and test them in processes that work directly in live systems.

FOOTER CAN GO HERE 5