Manage multiple repositories
By default, a Ranorex Studio project contains a single repository file that’s used automatically for each new recording module. You can manage all repository items that your modules reference in a single repository, but there are also good reasons for having multiple repositories in a single project. This chapter explains these reasons and describes how to work with multiple repositories.
In this chapter
Reasons for multiple repositories
Testing different user interfaces
Let’s say your test suite contains test cases for a web application and test cases for a user interface of a client application. In this scenario, using two repositories would make sense. One would contain the repository items for the web application, while the other would contain those for the client application. You could also separate the repository items for both applications in a single repository by using simple folders, but using two repositories is more convenient, especially when working in a team.
It’s a good idea to modularize repositories in a way similar to recording and code modules. For example, when you think about a rich client application with main menus, ribbons, or toolbars, you would create small reusable recordings for clicking UI elements in the main menu like File > Open > Handle the Open File Dialog etc.
All these reusable modules work with the main menu, the main toolbar or similar, i.e. shared controls. Therefore, it’s a good idea to also base them on a repository which exclusively represents these shared controls.
Advanced RanoreXPath Expressions
Another reason to build a separate repository could be to store advanced RanoreXPath expressions which should exclusively be used to create new actions manually instead of recording them.
Multiple testers on the same project
While working alone on a project, a single repository is often sufficient and usually won’t be an issue. However, when working with others, this can quickly result in conflicts. This can be circumvented by using multiple repositories. Also make sure to set up rules and responsibilities, like: Who may rename repository items? Who may restructure repositories? Who may delete items?
Some of our customers have tests with millions of repository items. It’s quite obvious that keeping all of them in one repository would make it incredibly hard to maintain, not to mention the file size of such a repository. As your tests grow larger, think about how you can sensibly divide your repository items into different repositories to keep them maintainable and performant.
Add a new repository
Adding a new repository
In the Studio toolbar, click the Add repository button.
The repository template is preselected.
Name the repository.
- The new and empty repository is added and can be seen in the projects view.
Newly added repository file with code representation and image hosting file.
Assign a repository to a module
Once you have more than one repository, you can assign them to different recording modules. You can then use the repository items of that repository in the recording.
Currently assigned repository
The currently assigned repository is displayed in the repository’s toolbar when a recording module is opened.
Current repository assignment
The recording module
… has the repository
IntroductionRepository assigned to it.
Assigning a different repository
In the repository toolbar, click the currently assigned repository.
In the drop-down menu, click the repository you want to assign.
Assigning a different repository
The currently assigned repository. In this case, it’s the default repository.
The other available repository,
If your recording module contains actions that are linked to repository items from the currently assigned repository, you can choose to have Ranorex transfer these repository items to the newly assigned repository.