Forum Discussion

JennyH11's avatar
JennyH11
Frequent Contributor
7 years ago

Objects being reused and renamed causing tests to break

Hi All

 

I've just started testing a release in TestComplete, expecting to have to make some late changes etc. However, I'm finding that many frequently used objects in my tests are no longer in existence. They have either been renamed (reused for new functionality) or are completely different to what was there before.

 

I accept that I'm going to have to make some changes to get these to run - frustrating as I'd spent a lot of time stabilising but what I would like to know is, is there any best practice guidance I can feedback to our development team to try and alleviate the pain this causes me when I run tests against our software.

 

I get that things change and tests need to be updated but I can't help but feel that there are some common problems which might be avoidable.

 

Any help anyone can offer would be appreciated!

 

Many thanks

Jenny

9 Replies

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

    I feel your pain.  An update to a new version of BootStrap was just applied to our application under test... and of the 121 test cases we have defined for it, all of them failed.  The reason for our failures are all object identification issues.  Either the new version of bootstrap has altered the hierarchy of the objects (added or removed a DIV panel) or some other identifying factor has changed (objects that used to have an object label no longer do, className property has changed in value, etc). 

     

    For us, there's not a lot that the development team could do.  However, one thing that has remained consistent is that, when we're using the ObjectIdentifier or idStr property, that stuff hasn't changed.  While hierarchy changes are a bugger to deal with, there is some mitigation that can happen where you implement the "Extended Find" to account for some of those differences.  

     

    However, ObjectIdentifier is your key.  I don't know if you're testing a web app or a desktop app, but either way, if you can have your developers give you at LEAST one property on every object that has a static identifier, that will make your object identification issues MUCH less painful.  It won't take them ALL away, but it will at least give you a consistent scheme where your application will always identify the same objects with the same properties.

    • JennyH11's avatar
      JennyH11
      Frequent Contributor
      7 years ago

      Hi Robert,

       

      Thanks for your advice.

       

      I have been able to work around this by using Extended Find on the object itself or a parent object. Though, I don't really like to use this as I understand it adds time to test runs and is already used a fair amount in the project.

       

      I have looked at the ObjectIdentifier property of some of the objects already stored and most have nothing populated. I've also checked with a developer and they confirmed they don't follow any guidance at all concerning objects and\or coding for testing using TestComplete. This has prompted discussion internally :)

       

      It seems like a good suggestion to always have a static identifier on every object. That way the desired Object is always the one that TestComplete is looking for and it's less "hit and miss" as to which one it is actually looking for. The trick will be encouraging others to understand the importance of this from our perspective and following that guideline. *added to the list! ;)

       

      I'm glad you mentioned web testing as I am also having issues with identifying objects in those tests aswell! And your advice will no doubt help there aswell. Thank you!

       

      This might sound a silly question but I'll ask it anyway! - Is there any way I can create a unique Object Identifier on an object? I've noticed some of the Identification Properties can be edited - I might be wrong - and I just wondered if they could be used in that way. I understand this might be waaaayyy to simplistic but thought it worth asking just in case.

       

      Thanks for all your help!

      • tristaanogre's avatar
        tristaanogre
        Esteemed Contributor
        7 years ago

        While you can edit the properties in object browser, those edits will not persist.  Sorry. :(

  • KSQian's avatar
    KSQian
    Contributor
    7 years ago

    What stack does your tech team use?

     

    If they are C#, then they should adhere to an automationId just for you.

     

    https://msdn.microsoft.com/en-us/library/system.windows.automation.automationelement.automationelementinformation.automationid(v=vs.110).aspx

     

    But if they are adding and removing elements all the time, that probably indicates the app itself isn't even at a stable state for you to spend time automating. 

     

    They should also adhere to a design methodology that is sensible. For example lets say they have a panel (in a C# app, webapp whatever) called customerOrders. and within the customerOrders they have an inputfield called 'address'. It is sensible that if I find the customerOrder panel, then look for address, I should be getting the customer address field, even if 'address' itself is a bit ambiguous. 

     

    If dev change that, they may put a wrapper around address or whatever. But fact is from design, if I go find a customerOrder panel then look for address, I should still arrive at the same object. 

     

    Not sure if that makes any sense.  

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

      Also get involved in the design process.  You may not be able to convince the devs to stop making changes that affect your tests so badly, but at least you will know what's coming before it lands on your desk for testing.

      • JennyH11's avatar
        JennyH11
        Frequent Contributor
        7 years ago

        Thanks Marsha!

         

        This is what I'm striving for, however, there are many challenges, more than I can take on on my own at present and I have to pick what I can tackle aswell as what I'm already doing.

         

        Thank you for the reminder though, for me this is the crux of the problem. I am simply not involved enough at the design stage.... My instinct tells me that currently we do not have enough of a "design stage" and decisions are mainly left to the developer and myself and another colleague are surprised when we see the end result. It will improve because it has to and we'll keep pushing.

         

        Thank you for your input Marsha!

    • JennyH11's avatar
      JennyH11
      Frequent Contributor
      7 years ago

      Hey!

       

      Thanks KSQian!

       

      We are using Delphi7 currently and going through the process of upgrading to XE at present. Shame on us, I know. Firstly using Delphi but then also upgrading to a version that is not the latest. This is where we find ourselves however.

       

      They aren't adding & removing objects all the time as such, it's more that the hierachy of an object or two had changed. It feels a much bigger problem when it happens, probably because of the frequency of the the interaction with the objects in question. It was a pretty daunting feeling at the time, thinking I was going to have to sit there and manually fix each step!! Not good. Sorry, if that was misleading... Saying that, object recognition is a common problem for us, but this is the first time the cause has been the addition of new objects and changes in hierarchy.

       

      As for any wrappers being implemented I'm not sure. I understand your point though and believe the object hierarchy that we have does make sense in this way, which is a help.

       

      Thanks for your help!