Forum Discussion

mikev's avatar
mikev
Contributor
13 years ago

NameMapping, Mapped Objects & Aliases - 101

I'm new to TC, and have just found out something that I didn't quite expect.  In designing and coding my test, the GUI (Java Application) was fairly static until today.  I needed to update the GUI, and I ran the test.  The GUI had new objects on it, which is fine.  However, many of the objects that I have in the Aliases pane were no longer found.  I thought that was kind of odd, and a little bit frustrating.  As it turns out, the path to the objects (and by path, I mean in Java applications, you typically have objects laid out in some sort of form, panel, etc) was now changed because of the new object editions.



So here's what I think is going on, and I'm sure there's a better way to figure things like this out when the GUI changes.  I notice that while learning objects, you must learn the entire path to  that object, from Sys on down.  When you are learning those objects, you have the option to "skip" the current object and only map (in the Aliases section) the objects that you plan on manipulating.  So far, so good.  Since my existing objects were not found, I learned one of them again, changing the name, and then I found out where TC thought it should be (Find Mapped Object).  Turns out that the objects were now in a different pane (i.e. path) than before.  The solution was to just drag the object to the right location in the tree.  That's not so bad if you only have a few objects to do, but if you have a whole bunch, it's really time consuming and frustrating.



How do the rest of you handle GUI changes as they relate to the NameMapping?  I'm pretty sure there's a better way to do what I've done, I just don't know what that is.  The "skip" option really only means that you are not learning the object for the Aliases, but you must learn it for the Mapped Objects.  I would think that if the description to the object that I want to manipulate is unique (like Name, AccesibleName, etc.) that it should not matter at all where on the application it exists.  Is the only way around this is to use FindChild?  I'm looking for some way that my objects will be recognized when the GUI changes.
  • chicks's avatar
    chicks
    Regular Contributor
    13 years ago
    Mike,;



    I don't use the name mapping because it doesn't provide the level of control I'd like.  What I do is have an objects file, with a function for each object I care about.   The find function returns a stub object if the item is not found....



    //   here's the code in the actual t est

      Click( memberPortal_Link_Logout() );



    // here's the definition of the logout button

    function memberPortal_Link_Logout(){return memberPortal_topPanel().Find(new Array("ObjectType", "innerText"), new Array("*Link*", "*Logout*"), FIND_DEPTH);}



    // here's the Click routine, which handles the object not existing case

    function Click(linkOrButton)

    {

    if(linkOrButton.Exists)

      {

       linkOrButton.Click();

       Sys.Process("iexplore").Page("*").Wait();

      }

    else

     {

      Log.Error("Couldn't find object to Click.");

       //throw exception;

      }

    }



    Regards,  Curt


  • mikev's avatar
    mikev
    Contributor
    13 years ago
    Thanks Curt, that's what I was thinking that the only real way around this is to use Find, FindChild, etc.  It does pose a few issues though. First, it kind of defeats the purpose of the NameMapping file.  Second, there may be multiple things that I want to do to an object.  For example, in a combo/list, I may want to select one, multi-select, right-click, etc.  I only see two options in doing that:  create a function that describes the object and performs many different operations on it, thereby making it a much larger function that it needs to be, or create a single function for each operation with  he description being the same in every function.  Either way, it's more difficult to maintain, and you have to be careful on the test setup in the way that you call the functions.  Hmm.  Too bad that we can't somehow describe the objects in the NameMapping file in such a way that it doesn't matter where on the application it's located.  That way the test will not break when things are added or deleted.