Handling Object Changes mechanism from one to another build in the desktop application

Curious if Build 1 and 2 are being done on the same machine?

If not then find the difference between the two machines.

So they added a new container layer?

ie - SwingObject("PanelDate", "", 0)

There isn't a great deal you can do to mitigate it if it's a completely new layer.

But you can make script maintenance easier (assuming you're using object map + aliases). If you have an Alias set up for the end control you actually interact with (in this case - SwingObject("JFormattedTextField", "", 0)) then I would exclude the new layer from the alias reference. So the reference used in the script would not change. Of course, this assumes that the new PanelDate object is only a container, and not something you would ever reference directly with, or interact direct with, in a script.

Update the object map so the existing alias become valid again. Then you only need to update the map. The alias remains the same. The reference to the alias in all your scripts remains the same. Minimum maintenance. Only possibly if you make good use of aliases.

That's the approach I use and it works well for me.

Hi,

> How are we going to address these kind of challenges in our automation scripts?

If you are using Aliases and Namemapping, consider use of the Extended Find functionality in NameMapping (see help and https://support.smartbear.com/screencasts/testcomplete/reliable-tests-for-dynamic-objects/ from https://support.smartbear.com/screencasts/testcomplete/ for more details).