I am currently evaluating a number of tools for automated test of a standalone GUI application.
I have searched the forums for additional info which has helped somewhat. Unfortunately I am not a tester or coder.
That said I have created a small script with Robot to loop through a screen of my application and enter invalid data into a field using a datapool. When this data is invalid a windows object is displayed (which is basically a (!) graphic)indicating this.
Problem being that I am using this windows object as a Verification Point and it not only changes within each iteration of the test but changes upon a new version of the AUT.
The windows object is "Class=WindowsForms.Window.8;ClassIndex=23"
Now this changes between 23 & 24 in my current version of the AUT and upon running a new version the two numbers change. Now I can get around the two changing in the same iteration by choosing both (or), but still would have to manually change my code with each release of the AUT.
I believe from what I have read (here and elsewhere) that I can fix this name within my script so that it will not change on each release? Is this so?
I am simply evaluating this tool at present and I am only looking for confirmation and advice rather than in depth explanation, your opinions are valued.
Re: How to handle Windows Forms Class names changing?
Here is the deal... The window is not named or uniquely identifiable. So Robot is automatically adding an index number to it so it is unique. It uses the next available unique number. So if there have been or are 22 other similar windows then it will number the next index 23. Keep in mind, the windows don't all have to be on the screen at the current moment to get the next index. They had to have existed at some point while Robot was running.
Two things you can do.
1) Ask your dev team to create different warning windows that are properly named for automation (unlikely, but worth a shot)... Bring Donuts!
2) Write more code that loops through each index of that window type checking for the visible property to be true. If you find it, examine it's text and see if that is the window you want to operate on. If it is, do your stuff. This requires you to get rid of the built in VP, which I always recommend anyway because you can do more powerful things that are less fragile if you code the VPs yourself.
Keep in mind that any automation tool will have this same or very similar issue with an object that is not uniquely identifiable.
If this or any response has helped you, please reply to the thread stating that it worked so other people with a similar issue will know how you fixed your issue!