Multiple repositories | Ranorex
HomeUser GuideRanorex Studio FundamentalsMultiple repositories

Multiple repositories

By default, each Ranorex Studio project contains one repository file which is automatically used for each newly created recording module. You can manage all UI-elements of a test suite project in a single repository file, but there are several reasons for having multiple repositories within a test automation project. This chapter is to introduce and explain the options for multiple repositories.

In this chapter

    Reasons for multiple repositories

    Testing Different User Interfaces

    If your test suite contains, for example, test cases for a web application and tests for a user interface of a client application, it might be useful to have two repositories. One is used to manage the UI-elements of the web application while the other exclusively stores the elements from the client hosting application. Although you can separate things from one repository using simple folders for grouping, it makes sense to divide it up – especially when working in teams.

    Common Repositories for Common Modules

    Repositories can (and should) be modularized and reused in the same way recordings and code modules are. For example, when you think about a rich client application using main menus, ribbons or toolbars you would create small reusable recordings for clicking on the main menu ‘File’ | ‘Open’ | ‘Handle the Open File Dialog’ | etc.

    All these reusable modules work with the main menu, the main toolbar or similar, commonly available controls, and should be based on a repository which exclusively represents commonly used controls on the user interface.

    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

    As long as you’re working alone on a test automation project it’s not a problem to work with one single repository. When working in teams and everyone in the team only clicks the ‘Record’ button to create test automation modules, it is recommended to keep in mind who is responsible for the main repository.

    Who is allowed to rename objects and to re-structure the repository? The main reason to separate repositories is to avoid accidental damage to repository items which are used by other team members.

    Repository storage location

    Repository information is stored in repository files. Repository files can be viewed from within Ranorex Studio or the project file structure of your local Ranorex installation.

    Repository files in Studio project file view

    Repository files in Studio project file view

    Default repository

    • The repository file has the file ending rxrep which stands for Ranorex repository file
    • The default file name is a combination of the corresponding name of the test solution (i.e. Introduction) and Repository

    Repository code representation

    • The file with the ending .cs is the code representation of the repository in C# language

    Image hosting file

    • The file with the ending .rximg hosts all images (screenshots) referring to the repository items

    The files have their representation in the project file structure of your local Ranorex installation

    File representation of repository

    File representation of repository

    Note icon

    Note

    The default repository is the one that gets bound to a new recording module by default. A different repository needs to be assigned to a recording module.

    Renaming repositories

    Repositories can be renamed at any time.

    Renaming repositories

    Renaming repositories

    Select the repository file in the project file view of the working environment
    Open the context menu and click Rename, or press F2
    See the changed repository including all corresponding files

    Deleting repositories

    Select the repository file in the project file view of the Studio working environment
    Press DEL, or use the context menu to delete the repository

    Result(s):

    • If no repository item is referenced, the deletion will be executed smoothly
    • If at least one repository item is referenced, a corresponding information requires your additional confirmation
    Repository deletion confirmation

    Repository deletion confirmation

    Note icon

    Note

    Remember that repository items may be referenced outside of the current test solution.

    Adding a new repository

    This section shows how to add a new repository to the current test solution.

    Adding a new repository

    Adding a new repository

    Click the Add repository button in the Studio toolbar
    A new repository template is pre-selected
    Give the repository a meaningful name
    Click Create to finish

    Result(s):

    • The new and empty repository is added to the current default repository and can be seen in the project file view of the test solution
    Added repository

    Added repository

    Added new repository file with code representation and image hosting file
    Default repository

    Assigning a repository

    The purpose of multiple repositories is to assign different repositories to selected recording modules within test projects. Here is how to do this.

    Current assignment

    The current assignment between a recording module and a repository can be seen in the Studio working environment.

    Current repository assignment

    Current repository assignment

    Current recording module Recording1.rxrec is assigned to …
    … the current repository IntroductionRepository

    Assigning a different repository

    1. Open the repository management menu in the repository toolbar
    Assigning a different repository

    Assigning a different repository

    See the default repository at the first place in the list of available repositories
    See a second repository DatabaseTesting with its belonging to the test solution Introduction
    If the assignment of a new repository affects references to repository items, you are asked how to treat the affected items

    Embedding a repository

    Usually, repositories are managed separately from recordings within the test solution. The separation of actions (i.e. action items within recording modules, or code actions within code modules) and the management of UI-elements (i.e. repository items within repositories) have many advantages. The possible re-use of UI-elements in different recording modules is only one of them.

    But sometimes it might be necessary, or useful to bind a set of UI-elements more closely to corresponding actions. This is where embedding a repository comes into play.

    Open the repository menu and click Embed repository to embedd the currently selected repository
    Embedding a repository

    Embedding a repository

    Default repository file representation
    Recording module Recording1 with code and user-code representation
    Recording module Recording1 with embedded repository files

    Important to know:

    • All changes which are made within the recording module and its embedded repository are capsuled to the actions of the recording module and its repository
    • The changes do not affect the regular repository being valid for all other recording modules within the test project