Forum Discussion

habhoub's avatar
habhoub
Occasional Contributor
7 years ago

Problem in Name Mapping shared objects! Needs Help

Hello

 

we are a team of 4 users, starting working on GitHub on a TestComplete project, we are facing an issue when merging our projects files in NameMapping objects, as on some machines the list of objects is not complete and so some controls are not found using the object name "Aliases.etc..."

 

Do you have any suggestion for the solution?

Question: Usually, the names gotten from the object Spy are exactly the real names of the controls in the code of the project right?

If some objects are not added to the name mapping and a user wants to use a test calling these objects by their alias names, does this include an issue? (example: Aliases.NovoClinicalTrialsManager.FrmMain.TableLayoutPanel1.TableLayoutPanel2.HeadlessTabControl1.TabPage10.SponsorsList1.NavigableDataControl1.Body.SponsorDetails1.flwMain.ctlContacts.tblContacts.btnNew)

 

and why?

 

Thank you

 

    • tristaanogre's avatar
      tristaanogre
      Esteemed Contributor
      7 years ago

      Another practice mentioned several times at the recent connect conference was to designate a "master" of the NameMapping for your team.  That person would be responsible for maintaining and developing the object mapping.  This could take various forms, two of which are:

       

      1) The person does ALL the mapping.  For every test case, the person would map all new components that are needed, check the altered NameMapping file into the source control, then everyone would retrieve that file and utilize the mapped objects.

      2) Everyone maps their own components.  Then the master uses the built in "merge" option to merge all the separate files into a single file, uploads that file to source control which then everyone retrieves for their work.

      • Marsha_R's avatar
        Marsha_R
        Moderator
        7 years ago

        tristaanogre's #2 is what we use with 4 people and it works pretty well.  I wouldn't go more than a couple of weeks between merges or it gets too messy.  Our teams with more than 4 people use approach #1.  

  • AlexKaras's avatar
    AlexKaras
    Champion Level 3
    7 years ago

    Hi,

     

    The recommended practice for TestComplete is not to merge any project files. (Script units with script code is an exception but even these files must be merged often. Daily at least.)

     

    If some object does not exist in NameMapping and Aliases it obviously cannot be used in tests because TestComplete runtime has no idea what real object in the tested application should match that Alias.

    • habhoub's avatar
      habhoub
      Occasional Contributor
      7 years ago
      Hi, in order to avoid this risk in using the aliases names in namemapping, what do you think about using the fullname of the controls instead of their alias names? Is it a good and safe idea?

      Thank you
      • AlexKaras's avatar
        AlexKaras
        Champion Level 3
        7 years ago

        Hi,

         

        > Is it a good and safe idea?

        Silver bullet does not exist and every solution is usually a result of several trade-offs and is located somewhere in the middle between extreme conditions.

        Full name of the object is its full absolute name :) and corresponds to this exact physical control. If/when developers change control type, its location within objects hierarchy or its identification properties you will have to update your test code appropriately.

        NameMapping is (among other useful things) a translation table that makes it possible to create a logical name to be used in test code and bind this logical name to the physical one. So, you will need to adjust only NameMapping when something changes for the mapped control. Test code stays unmodified.

        Aliasing is the next level of NameMapping abstraction. Aliases refer to NameMapping (and through it to physical controls) and make it possible for you to organize controls tree for your tests in a way that is more logical and convenient for test code from end-user and tester point of view.

         

        Summary:
        -- Use of Full Names only will result in a hardly maintainable code;

        -- By creating wrapping functions that return objects by their Full Name you will (less efficiently) duplicate NameMapping functionality;

        -- Usually, the best approach is to create a reasonably small basic NameMapping tree and map skeleton elements of your tested applications UI. Then, using these skeleton elements as search roots, use .FindXXX() methods to search for dynamic elements that are either difficult or not worth to NameMap (e.g. table cells, drop-downs, etc.)