Forum Discussion

jmassey's avatar
jmassey
Contributor
8 years ago

Default / Preferred Name Mapping Properties

I've been trying to run this down in the docs but I just keep going in circles. Is there anywhere listed which properties will by default (i.e. assuming you have no templates or anything) be used when adding an object to the Name Mapping repo, and in what priority order? I'm trying to put something together for our devs so that they have a better idea what types of changes are likely to affect automation. I could swear I saw something somewhere once about what properties are the default and fallbacks, but I can't find it, now.

4 Replies

Sort By
  • tristaanogre's avatar
    tristaanogre
    Esteemed Contributor
    8 years ago

    Most of the time, it's ObjectType and ObjectIdentifier.  Not sure where it is in the docs.  And, honestly, ObjectIdentifier isn't always automatically added.  

     

    I'll step in for Colin_McCrae here and say that it's really not a good idea to always stick with the default mapping.  There's only so much "smart" that can be encoded into the automatic name mapping. When mapping, it's pretty much a best practice to over-ride whatever defaults are added with your own criteria.  Using templates is the best way.  Going that route, also, you can build your own criteria set to then give to your developers to let them know what and what not to do.

  • m_essaid's avatar
    m_essaid
    Valued Contributor
    8 years ago

    I just want to say that the dev team doesn't have to take in consideration your scripts... They just modify their components as they have to do, and you have to adapt your script at any time... it's quite a pain but it's your problem, not the dev team's one.

    • tristaanogre's avatar
      tristaanogre
      Esteemed Contributor
      8 years ago
      m_essaid wrote:

      I just want to say that the dev team doesn't have to take in consideration your scripts... They just modify their components as they have to do, and you have to adapt your script at any time... it's quite a pain but it's your problem, not the dev team's one.

      I disagree.  The dev team has a vested interest in your test automation in that it is one of the ways that flaws that they may not have anticipated can be discovered before they hit the field. A good partnership with the developers makes for successful test automation.  It is to their advantage to make sure that, as much as possible, they keep the automation running smoothly and, if nothing else, being informed as to what changes may "break" your automation will give them the information they need so that they can pro-actively inform you that a change is coming down the road and you can make preparations and plans.  In my greatest successes with test automation, the developers sat with me, side by side, as I was debugging and developing stuff and actually built in little hooks and such to make my job easier. I had one developer for a web application I was developing add a particular attribute property to some of the components to make it easier to find and identify the components.  This made my automation work SOOOOO much easier that I was able to turn around tests faster and give them faster feed back. For that matter, involving the developers lets them know that you're not their adversary but their partner in ensuring good quality software. So, yes, DEFINITELY involve your developers.  You're on the same team.

       

       

      • shankar_r's avatar
        shankar_r
        Community Hero
        8 years ago

        To be honest, Both Developers and Automation testers  work collaboratively in-order to make Automation scripts to be efficient as well as a product.

         

        I have came across some stages where developers needs to be involved in helping automation testers.

        In our JSwing AUT there some controls will get it displayed during rendering for example table load time [In out AUT there are more-then 50 tables that we are verifying], Test Complete not able identify the table load time and there was no property found to know when the table gets loaded. 

        We have asked dev team provide a flag or function that will return the status of the table load. With that function we are able to identify the table load time. 

         

        So, ultimately we may need dev help at some point in every automation.