Forum Discussion

JamesP's avatar
JamesP
Occasional Contributor
5 years ago

Object mapping for multiple environments

Hello,  I am new to TestComplete v14.5 and am preparing some keyword tests to be used across all of our test environments. I have found that the name mapping uses the full URL by default to id the ...
Name Mapping
Object Recognition
Recording
  • AlexKaras's avatar
    AlexKaras
    5 years ago

    Hi,

     

    > proper Name Mapping to ensure that it defaults to the Aliases

    Well, there is some architecture that is good to be aware of:

    -- Tested application contains some object that you'd like to interact with in test code. This (let's call it physical) tested object contains some properties with their corresponding values. Also this object is located at some level within the objects' hierarchy that exists in the tested application. This is the lowest layer;

    -- Next NameMapping goes. NameMapping may be considered as a table that specifies the rule(s) that let test code to find the tested physical object. The proper set of rules (unique and stable identifiers, depth of search, conditional search, whether or not try to search down the objects' hierarchy) makes it possible for test code to find the tested object when the internal structure of the tested application changes (to some extent) during development or when the values of the properties that are used for object's identification change (for example, when testing on different environments). However the NameMapping itself is not perfect: it depends on the physical objects' hierarchy and might be changed when this hierarchy changes during development (for example, if tested objects are moved from one parent to another or some parents are added or removed). NameMapping is at the middle layer;

    -- Aliases are at the highest level and their purpose it to make your test code to be as independent from the tested objects' hierarchy changes as possible. Aliases are located on top of NameMapping and are linked to it. You can adjust the structure of the Aliases tree very significantly but every element of Aliases tree remains to be linked to its corresponding NameMapping element. Which, in its turn is 'linked' to the physical tested object. So you may consider NameMapping as a translation table between Aliases (that correspond to the tested objects' hierarchy that is convenient to you as a user) and physical tested objects in the application. Note, that, for example, if because of changes in the objects' hierarchy in the tested application NameMapping must be changed (some NameMapping elements must be moved up or down the hierarchy or some new elements must be inserted in-between or removed), those changes will not alter Aliases tree and thus your test code will remain unchanged. Actually, there is no need to use NameMapping object in test code and Aliases one should be preferred one.

     

    With the above in mind, the best strategy with automation with TestComplete is to investigate your tested application before test recording and create NameMapping and Aliases elements that identify the elements you will interact with during recording. In this case TestComplete will use Aliases elements during recording. Also with manual preliminary Aliases design you will get more clean and clear objects tree that better corresponds to the tested objects' hierarchy from the end-user point of view (more flat structure, absence of not necessary intermediate panels, more descriptive names, etc.)

     

JamesP's avatar
JamesP
Occasional Contributor

Hi Alex,

 

Thanks for highlighting that.

I can see that there is a mix of Aliases. and NameMapping.Sys.browser. in my keyword tests.

How do I prepare a proper Name Mapping to ensure that it defaults to the Aliases ?

AlexKaras's avatar
AlexKaras
Champion Level 3
5 years ago

Hi,

 

> proper Name Mapping to ensure that it defaults to the Aliases

Well, there is some architecture that is good to be aware of:

-- Tested application contains some object that you'd like to interact with in test code. This (let's call it physical) tested object contains some properties with their corresponding values. Also this object is located at some level within the objects' hierarchy that exists in the tested application. This is the lowest layer;

-- Next NameMapping goes. NameMapping may be considered as a table that specifies the rule(s) that let test code to find the tested physical object. The proper set of rules (unique and stable identifiers, depth of search, conditional search, whether or not try to search down the objects' hierarchy) makes it possible for test code to find the tested object when the internal structure of the tested application changes (to some extent) during development or when the values of the properties that are used for object's identification change (for example, when testing on different environments). However the NameMapping itself is not perfect: it depends on the physical objects' hierarchy and might be changed when this hierarchy changes during development (for example, if tested objects are moved from one parent to another or some parents are added or removed). NameMapping is at the middle layer;

-- Aliases are at the highest level and their purpose it to make your test code to be as independent from the tested objects' hierarchy changes as possible. Aliases are located on top of NameMapping and are linked to it. You can adjust the structure of the Aliases tree very significantly but every element of Aliases tree remains to be linked to its corresponding NameMapping element. Which, in its turn is 'linked' to the physical tested object. So you may consider NameMapping as a translation table between Aliases (that correspond to the tested objects' hierarchy that is convenient to you as a user) and physical tested objects in the application. Note, that, for example, if because of changes in the objects' hierarchy in the tested application NameMapping must be changed (some NameMapping elements must be moved up or down the hierarchy or some new elements must be inserted in-between or removed), those changes will not alter Aliases tree and thus your test code will remain unchanged. Actually, there is no need to use NameMapping object in test code and Aliases one should be preferred one.

 

With the above in mind, the best strategy with automation with TestComplete is to investigate your tested application before test recording and create NameMapping and Aliases elements that identify the elements you will interact with during recording. In this case TestComplete will use Aliases elements during recording. Also with manual preliminary Aliases design you will get more clean and clear objects tree that better corresponds to the tested objects' hierarchy from the end-user point of view (more flat structure, absence of not necessary intermediate panels, more descriptive names, etc.)

 

  • JamesP's avatar
    JamesP
    Occasional Contributor
    5 years ago

    Alex,

    thanks for having taken the time to send me a clear description of how the Name Mapping/Alias structure works on top of the "physical" layer. The pre-mapping strategy is a good one and I will use it as I design my next tests.

     

    Kind regards,

    James