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.

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.

Modularizing repositories

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?

Complexity

Some of our customers have tests with thousands 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

Result(s):

• The new and empty repository is added and can be seen in the projects view.