Forum Discussion

JaredBill's avatar
JaredBill
Occasional Contributor
13 years ago

Changing Objects

Hello all,

    I have been facing an issue in my automated scripts using TestComplete and I'm curious if anyone else has experienced this.  What will happen is that I spy on an object and record the object (see below), write my script and then at some point in the future when I run my test it fails.  At this point I spy on the object again and it has changed.  I know this sounds bizarre but I have had this happen to me more than 10 times now.  See my example below and note that the two objects are the same, just written differently:



First Time I spy'ed:

Aliases.ws32.frm_All.lst_UnderlyingPortfolios.lst.lst







Second Time I spy'ed:


Aliases.ws32.VBObject("frm_All").VBObject("lst_UnderlyingPortfolios").VBObject("lst").VBObject("lst")




Any thoughts on configuration within Test Complete that could correct this?  Please note that these two session were against the same software build so there is no chance that the object actually changed.  The issue seems to be within TestComplete and how it's viewing objects.  Is it possible that if you have recorded the object in your current session that Test complete will use a different version than if you did not(reaching for some logical answer).  If so, how can I stabilize this so that I always see the same object?



TestComplete Program Version: 7.52.678.7

Microsoft XP Pro Service Pack 3



Thank you in advance!

-J

8 Replies

Sort By
  • JaredBill's avatar
    JaredBill
    Occasional Contributor
    13 years ago
    P.S.  I have confirmed that this is directly related to recording.  In the above example, I recorded the object in question and then spy'd
    on it the third time, it went back to what it was
    orgionally.



    I'm looking through Test Completes options now but I haven't found anything that seems that it would impact this.
  • tristaanogre's avatar
    tristaanogre
    Esteemed Contributor
    13 years ago
    Aliasing and name mapping utilizes a number of properties to identify objects.  It is possible that, between the two instances, the identifying properties on your objects no longer match what's in NameMapping and so they resolve differently.



    I'm working with another user here http://smartbear.com/forums/forum/post/?mode=singleThread&thread=4beb0fb4-9d9b-464f-807e-6b747423deb2#last that is experiencing some similar situations.   There are a couple of article links I through into that thread that might interest you as well in figuring this out.
  • JaredBill's avatar
    JaredBill
    Occasional Contributor
    13 years ago
    I think that article is going in a different direction than what I'm describing.  IN that persons case the problem is a dynamically created object and the solution is to generalize the name mapping value so that it no longer looks at the new ID each time the browser is launched.  In my case the object i'm viewing should remain static, it is part of a client application.  I am investigating the following option to see if it might be the culprit.  Ideas?



    Engines
    > General > Object Naming > Use short names when possible



    Thanks again!
  • JaredBill's avatar
    JaredBill
    Occasional Contributor
    13 years ago

    OK, so I don’t think that fixed it, I just
    experienced the same thing:


    Before recording:


    Aliases.ws32.frm_PortfolioQuickView.VBObject("fraNotificationsDisplay").VBObject("chkStatus_3")


     


    After recording:


    Call
    Aliases.ws32.frm_PortfolioQuickView.fraNotificationsDisplay.chkStatus_3

  • tristaanogre's avatar
    tristaanogre
    Esteemed Contributor
    13 years ago
    Well, actually, you probably have it set up to automatically map objects on recording.  So, before recording, you're seeing the Unmapped names of the objects... after recording, you're seeing the mapped names.  This is expected behavior with that option turned on.
  • JaredBill's avatar
    JaredBill
    Occasional Contributor
    13 years ago
    Agreed, the problem is that at a later time, after I have recorded and the name mapping has occurred, the script breaks down on playback because TestComplete is now looking for the raw object again for some odd reason.



    Take my newest example:



    In my code I use the value "Aliases.ws32.frm_PortfolioQuickView.fraNotificationsDisplay.chkStatus_3"  this is the name mapped value.



    Later on I run the script and it breaks down because it can't find "Aliases.ws32.frm_PortfolioQuickView.fraNotificationsDisplay.chkStatus_3"  it is now looking for "Aliases.ws32.frm_PortfolioQuickView.VBObject("fraNotificationsDisplay").VBObject("chkStatus_3")"



    At this point in time if I do a new recording of the object, Test Complete will begin working acuratly again because it now knows the object as "Aliases.ws32.frm_PortfolioQuickView.fraNotificationsDisplay.chkStatus_3"  again.



    Does that make sense?





    Quick steps:

    1.  I record and get namemapped value

    2.  Use in my script

    3.  (at a later time)During playback Test complete looks for the Raw value

    4.  I record second time

    5.  Test Complete works again.
  • tristaanogre's avatar
    tristaanogre
    Esteemed Contributor
    13 years ago
    Well, the thing is, it's not LOOKING for "Aliases.ws32.frm_PortfolioQuickView.VBObject("fraNotificationsDisplay").VBObject("chkStatus_3")", that is what you're finding after the fact.  And this is symptomatic that the property values used for the name mapping are no longer valid for identifying the object.  Hence my original suggestion to look at the properties used for mapping fraNotificationsDisplay and chkStatus_3 to see if there are any properties being used that may be dynamic (Id, date, time, caption, etc.).  If there are, each time you run your tests, you have a hit-or-miss on your run because TestComplete will not be able to find it using the criteria.



    So, it still comes back to making sure that you have adjusted your mapping criteria to be more robust for the potential of dynamic property values.
  • JaredBill's avatar
    JaredBill
    Occasional Contributor
    13 years ago
    I'm going to have to investigate a little bit, thanks for your help!