A TestComplete project can contain only one Name Mapping repository. However, you can merge (in other words, import) data of external Name Mapping files into the Name Mapping repository of your current project. This way, mapped objects and aliases defined in external files become available to the tests in the current project.
For example, when developing tests in a team, QA engineers may map different areas of your tested applications. You can then merge all the Name Mapping repositories into a “master” repository for easier maintenance. You can share the resulting Name Mapping file across all the tests developed for your application.
RequirementsRequirements
-
The Name Mapping repositories you want to merge must have the same set of configurations.
-
Name Mapping repositories created in TestComplete versions prior to 14 must be converted to the current version format before merging. To do this, open the project that contains the needed Name Mapping repository in TestComplete. TestComplete will ask you whether to convert the project suite to the current version of TestComplete. Click Yes. TestComplete will convert the project suite’s files, including the name mapping file, to the current format.
How to merge
-
In TestComplete, open the project to whose Name Mapping repository you want to add external Name Mapping data.
-
In the Project Explorer panel, right-click the Name Mapping project item and then click Merge with.
-
Browse for the external Name Mapping file (.tcNM) whose data you want to import and click Open.
TestComplete will add the mapped objects and aliases from the selected external file to the current Name Mapping repository.
When merging Name Mapping repositories, only the current Name Mapping repository is updated. The external Name Mapping repository is not changed.
How merging works
The merged Name Mapping file gets a combined set of objects (in the Mapped Objects and Aliases trees) from the local and external Name Mapping repositories:
 Local Name Mapping |
 External Name Mapping |
 Merged Name Mapping |
| Note: | Highlighting in the image above is for demonstration purposes only. TestComplete does not highlight objects in the actual Name Mapping repository. |
Legend:
objects that were in both local and external Name Mapping files
objects from the local Name Mapping file
objects from the external Name Mapping file
Objects that were in the local Name Mapping repository only or in the external Name Mapping repository only will keep their images from their respective repositories. Objects that were both in the local and in the external repository will keep their images from the local repository.
If you copy a Name Mapping file, delete some objects from the copy and then merge it with the original Name Mapping file, the deleted objects will remain, because they may still be used in tests in the original project. For the same reason, if you merge a copy with some renamed objects, the resulting Name Mapping file will include both the original local objects and the renamed external objects.
Conflict resolving
A merging conflict occurs when two objects with the same name and in the same place in the local and external Name Mapping hierarchies have different mapping criteria. Typically, but not always, the conflicting mapped objects correspond to the same object in the tested application.
TestComplete resolves merging conflicts automatically. The result depends on whether the Name Mapping files were created separately (case #1 below), or the external Name Mapping file is a modified copy of the local Name Mapping file (case #2 below).
To understand how conflicts are resolved, see the Name Mapping files below. They have the same object hierarchy; the only difference is that the wndNotepad object in the external Name Mapping file has an extra property. This difference causes a conflict when merging the wndNotepad object.
 Local Name Mapping |
 External Name Mapping |
The conflict is resolved in one of two ways.
Case #1: The conflicting objects were added to both Name Mapping files separately. For example, the Name Mapping files are from different, separately created projects. Or if one Name Mapping file was created by coping another file, and the conflicting objects were mapped after copying.
In this case, the local and external objects are considered different objects, and the external object is imported with the _new suffix. Depending on the identification properties, both the original and _new objects in the resulting Name Mapping file may point to the same object in the application.
Case #2: The external Name Mapping file is a modified copy of the local Name Mapping file, and the conflicting object was mapped before copying.
In this case, the conflicting objects are merged into a single object with the following mapping criteria:
-
the mapping mode (basic or conditional), properties and property values of the local object,
-
the description (in the Mapped Objects tree) of the local object,
-
the Extended Find setting of the external object,
-
a combined Required Children set from both the local and external objects.
In our example, the wndNotepad objects being merged have different identification properties. According to the merging rules, the merged wndNotepad object gets the same identification properties as the original local wndNotepad object does.
TestComplete displays a message if there were conflicts during merging. You can then find the changed objects (for example, imported objects with the _new suffix), see if the resulting Name Mapping file suits your needs and correct it if needed. To learn how to search for objects in a Name Mapping file, see Search and Replace in the Name Mapping Repository.
See Also
How To
Adding Objects to the Name Mapping Repository
Name Mapping Configurations
Search and Replace in the Name Mapping Repository
Merging Files (Legacy)
Using Source Control Systems for Teamwork - Specifics