Best Practice for replacing Repository Items

Ranorex Spy, Recorder, and Studio.
loonquawl
Posts: 50
Joined: Wed Nov 22, 2017 10:08 am

Best Practice for replacing Repository Items

Post by loonquawl » Tue Jan 16, 2018 9:07 am

Hi,
i'd like to know the best/least disruptive way to solve the following scenario:
We have a repository, with many rooted folders, and many items to each root. One of the Items now _functionally_ stays the same (i.e. a buttonpress will have the exact same effect) while _programmatically_ (and therefore in terms of its XPath) completely changing.

Repository before:
RootA
-------RootFolder1
----------------------RootFolder2
-------------------------------------Item1
-------------------------------------Item 2

Repository after:
RootA
-------RootFolderA1
----------------------RootFolderA2
-------------------------------------Item1
-------------------------------------Item 2(now defunct)
RootB
-------RootFolderB1
----------------------RootFolderB2
-------------------------------------Item 2

Two actions need to be taken, and i'd like to know, as stated, the best practice on achieving them:
1) Group Items 1 and 2 in the presence of tens of other subroots and items on all roots that will not be grouped accordingly. As i understand it, logical folders can only exist as subfolders to roots, and therefore, because there are other items (not drawn) that belong into other groups, can not be used to to group Item2 and Item1 after the change.
2) Replace Item2(old) by Item2(new) in every instance in- and out-solution, including code-mentions of it.

Both i can solve, but the solutions are rather long-winded and painful, and as i suspect this occurence might be rather common, i hope that there is some smooth solution, maybe even catching bothb at once?

User avatar
Stub
Posts: 173
Joined: Fri Jul 15, 2016 1:35 pm

Re: Best Practice for replacing Repository Items

Post by Stub » Wed Jan 17, 2018 10:35 am

I usually create small static getters in my code modules that retrieve me the repository folder item I need, so my code references Item1 or Item2 through that. That helps minimise the code that changes when I move Item2 to another repository folder. Otherwise I just suck it up and fix any code that no longer compiles.

loonquawl
Posts: 50
Joined: Wed Nov 22, 2017 10:08 am

Re: Best Practice for replacing Repository Items

Post by loonquawl » Wed Jan 17, 2018 1:01 pm

While "suck it up and fix the code" was not quite the BP i was expecting :lol: , i thank you for your input.
But this only takes care of action 2(replace in code) - would you be able to advise on action 1 (group in repository) as well?

User avatar
Stub
Posts: 173
Joined: Fri Jul 15, 2016 1:35 pm

Re: Best Practice for replacing Repository Items

Post by Stub » Thu Jan 18, 2018 9:08 am

I don't really understand your item 1 I'm afraid.

loonquawl
Posts: 50
Joined: Wed Nov 22, 2017 10:08 am

Re: Best Practice for replacing Repository Items

Post by loonquawl » Thu Jan 18, 2018 9:24 am

We use the repository from inside the Ranorex Studio, so the UI is important to us.
As you can see in the Screenshot, there is a Root1, which has Items, logical folders and root folders as children. Take "Button_U" as example - it is right above Button_A, and Button_Ka which ist great, because they "do" very related things.
Now the SUT changes, and the Button_U , or at least a Button that does the exaxt same thing as Button_U did, is created differently, and therefore has its own root, Root2 (In the Screenshot that's Button_Op).
What i'd like to achieve is to have Button_Op (aka Button_U), Button_A and Button Ka in one folder, so i can easily find them. Or have some other recourse to easily visually group them.
Attachments
2018-01-18 09_10_04-Greenshot.png
2018-01-18 09_10_04-Greenshot.png (6.98 KiB) Viewed 467 times