Forum Discussion

vthomeschoolmom's avatar
vthomeschoolmom
Super Contributor
6 years ago
Solved

name mapping for test durability

I am in a unique position.  I am charged with functional test automation for my organization from scratch. I now that "big" UI changes are coming to the application thougth stratgists can't tell me exactly how "big". This is fine. What I am looking for in order to be as prepared as I can is every blog post, article or anything about using the name map to minimize the effect of UI changes to the tests. I am looking for both good advice and tales of woe (what not to do) if such exists.

 

Thanks a ton oh fearless experienced TestComplete peeps.

  • TestComplete NameMapping has "Configurations" where the mappings can be "versioned" in a way.  Look into whether or not that will solve some of your problems.

     

    Unfortunately, major UI changes aren't always simply a matter of changing properties but changing hierarchies as well.  Where you used to have Parent.Child1.Child2, now you may have Parent.Child1.Form1.Table1.Child2.  In these situations, it's a lot trickier to keep your Mapping working well across versions.  What I would suggest is for simple hierarchy changes, look into judiciously turning on Extended Find for some objects.  In my example above, I would turn on Extended Find on the Child2 object.  That way it would be found regardless of how many objects are between it and Child1.  I wouldn't turn on Extended Find globally, there is a performance hit there.  But turn it on as needed.  I would suggest that, once the smoke clears and you have time, go back and backfill the ancestors that extended find "jumped" over to resolve those performance issues.

     

    Investigate using other means of mapping objects.  NameMapping has "required children" and "conditional mapping" as features within NameMapping that allows for more variation in object identification.  Conditional mapping may be a good tool to use with your upcoming UI change.

     

    Also, don't be afraid of using wildcards. Using the * symbol in a property value to partially wild-card an object makes things more robost if there are minor changes.

     

    One last thing -> Get cosy with your developers.  If there's this massive change coming up, odds are that they are already dealing with it.  They may have versions of the application already with those changes applied that they might be able to get you a copy.  Grab all the help you can to get ahead of the game with your mapping.  Use source control to version those mapping changes so that when the trigger is pulled, all you have to do is drop in the new NameMapping version.

     

    Be prepared for a lot of work.  It takes time.  Even if you weren't using NameMapping and were using some coded way of identifying objects, you would still need to go through and update ancestral hierarchies, property values, etc.  Make sure you communicate this to your superiors that they know that the automation you have may not run fully until this adaptation work is done.  It's part of the life cycle of the application.

     

    Good luck!  And if you need help, we're here.

4 Replies

  • tristaanogre's avatar
    tristaanogre
    Esteemed Contributor

    TestComplete NameMapping has "Configurations" where the mappings can be "versioned" in a way.  Look into whether or not that will solve some of your problems.

     

    Unfortunately, major UI changes aren't always simply a matter of changing properties but changing hierarchies as well.  Where you used to have Parent.Child1.Child2, now you may have Parent.Child1.Form1.Table1.Child2.  In these situations, it's a lot trickier to keep your Mapping working well across versions.  What I would suggest is for simple hierarchy changes, look into judiciously turning on Extended Find for some objects.  In my example above, I would turn on Extended Find on the Child2 object.  That way it would be found regardless of how many objects are between it and Child1.  I wouldn't turn on Extended Find globally, there is a performance hit there.  But turn it on as needed.  I would suggest that, once the smoke clears and you have time, go back and backfill the ancestors that extended find "jumped" over to resolve those performance issues.

     

    Investigate using other means of mapping objects.  NameMapping has "required children" and "conditional mapping" as features within NameMapping that allows for more variation in object identification.  Conditional mapping may be a good tool to use with your upcoming UI change.

     

    Also, don't be afraid of using wildcards. Using the * symbol in a property value to partially wild-card an object makes things more robost if there are minor changes.

     

    One last thing -> Get cosy with your developers.  If there's this massive change coming up, odds are that they are already dealing with it.  They may have versions of the application already with those changes applied that they might be able to get you a copy.  Grab all the help you can to get ahead of the game with your mapping.  Use source control to version those mapping changes so that when the trigger is pulled, all you have to do is drop in the new NameMapping version.

     

    Be prepared for a lot of work.  It takes time.  Even if you weren't using NameMapping and were using some coded way of identifying objects, you would still need to go through and update ancestral hierarchies, property values, etc.  Make sure you communicate this to your superiors that they know that the automation you have may not run fully until this adaptation work is done.  It's part of the life cycle of the application.

     

    Good luck!  And if you need help, we're here.

    • vthomeschoolmom's avatar
      vthomeschoolmom
      Super Contributor

      Some of what you say, I was aware of. Some not. As usual, you are the person with the best advice. I am mad fond of the name mapping features you describe, but never thought of them in precisely that way. I did not even know about configurations. Thanks for the help.

       

      Stephanie

    • vthomeschoolmom's avatar
      vthomeschoolmom
      Super Contributor

      Re: "One last thing -> Get cosy with your developers.  If there's this massive change coming up, odds are that they are already dealing with it.  They may have versions of the application already with those changes applied that they might be able to get you a copy. "

       

      I laugh to myself. I have already started this. It gets me in more strategy meetings. :)

  • karkadil's avatar
    karkadil
    Valued Contributor

    You are in a very good position!

    Spend all the time which left until the "big UI changes" take effect to learn TestComplete and create a pilot project. Then, when UI is changed, you will start from the scratch. It is not bad, pilot projects are often being abandoned.

     

    Anyway, even if you were a TestComplete expert, you wouldn't be able to predict all changes (which even your app "strategists" can't explain to you).