Project Organization: UI Components reusability (best practice)

Help
1

Hi everyone,

i was wondering what’s the best practice to create reusable UI Automation (non-ui) components (workflows) for an application.

Possible Options:
a) Create a Library with an .xaml for each of the reusable components (e.g. Login, Logout, Search xxxx, Close Window xxxx etc.) and then be used from within each project you create as Activity by injecting the Nuget package?
b) Create ‘Workflows’ and inject them every time in each project from a centralize repository?

What’s your experience so far and what do you think it’s the pros/cons for each option?

Thank you,
Tasos

2

@Anastasios,

As per my Understanding -

Creating a Library :

  • The other person has no idea of what is happening inside the component,
  • If customization is required , have to go to the component Developer.Dependency on the author

Directly Injecting Code -

  • Developers have access to the Code .
    -Easy to Follow and customization can be done.
  • No dependency on author , anyone can customize.

–
Mukesh

1 Like
3

I would say, you create as Libraries stuff that you are sure will not need to change very often and leave as open sequences for manually importing, thing that will have specifics to each project and will always need some editing to use…

4

Hi @Anastasios

Welcome to the community!!!

I would also like to add few points here…

I usually don’t recommend to have workflows that interact with UI elements as libraries. This adds the complexity, mainly because of the points mentioned by @mukeshkala. I know, workflows like login, logout can repeat time to time if multiple automation solutions are developed for the same system. In such cases, I would suggest to have those kind of workflows in a single location where we can just grab and include in our projects as workflows, but not as libraries… Why I say that is, because there can be needs to change some stuff over time…

However, commonly used workflows that do not contain UI interactions and mostly involve with complex logic etc… those can be included as Libraries which we are sure that it won’t run into errors or do not change just like my friend @bcorrea mentioned. These are very good choices to add as libraries…

This is the standard and the best practice I have introduced in our company…

1 Like
5

Hi !

my main purpose is to ensure that commonly used logic for UI Automation (e.g. SAP Login, SAP Logout, SAP Search xxx etc.) as mentioned above, will be identical across all the processes that make use of these components/flows.
So, i want to minimize the change impact and have a central repository of those objects. That way, every time something changes in an application - let’s say an element in SAP Login page - i won’t have to revisit all the .xaml files for SAP Login, but revisit only the central one that is used from all my processes that involve SAP - this is the main pillar of maintainability. Of course, for exceptional cases ,we will have to create new reusable flows or extend the existing to support new functionality, keeping always in mind the modularity.

Thank you guys!