Dealing with the changing GUI of the test application

Ask general questions here.
afrosteve
Posts: 17
Joined: Mon Feb 22, 2010 10:59 pm

Dealing with the changing GUI of the test application

Post by afrosteve » Wed Mar 17, 2010 8:43 pm

In designing an automated test suite, what's a good way in Ranorex to handle a possible change in GUI design when elements are moved around?

Is it just a matter of making code that searches for a general enough RXpath that as long the element you're searching for stays at the same level of the element tree, you will find it?

For example, make a path like:

Code: Select all

form///button
This will find a button in a form, two levels below the form root.

Suppose initially the button is located at:

Code: Select all

form/container/container['x']/button
but a developer then moves it to:

Code: Select all

form/container/container['y']/button
If I understand RXPath, Ranorex will find the button in both instances with perhaps a slight delay to walk to possible tree nodes.

What if the level of the element tree in which the GUI element you're searching resides changes?
For example, instead of

Code: Select all

form/container/container['x']/button
the button moves up a level to be

Code: Select all

form/container/button
Is it advisable to search in code using RXPath, or just build another repository?

Is this a good way to do it? Would an image based search be a better solution?

User avatar
Ciege
Ranorex Guru
Posts: 1335
Joined: Thu Oct 16, 2008 6:46 pm
Location: Arizona, USA

Re: Dealing with the changing GUI of the test application

Post by Ciege » Wed Mar 17, 2010 9:50 pm

Personally, I do not use the repository, but use a home grown framework that can find objects on a form regardless of depth or location as long as the object is named and there are no duplicates. (Duplicates can be handled but not in this method).

NOTE: Not using the repository may not be the best method for you...

This is my PushButtonClick method that will search for and click a pushbutton on a form. Note the use of FindSingle to search for an object (a pushbutton in this case).

Code: Select all

        public static int PushButtonClick(Ranorex.Form RanorexFormName, String PushButtonName, bool boolHideNotFoundError)
        {
            /************************************************************************
             * Function         : PushButtonClick(Ranorex.Form RanorexFormName, String PushButtonName)
             *
             * Description      : This function will search for and (if found)  
             *                  :  select a PushButton on the form.
             *                         
             * Parameters       : RanorexFormName   - The form object the the PushButton lives on
             *                  : PushButtonName    - Name of the PushButton to click
             *                  : boolHideNotFoundError - FALSE (default) - reports that the item was not found - returns -1
             *                  :                       - TRUE - Hides the error that the item was not found - Still returns -1
             *                  :                       - This option basically transforms this method into a check if exists method
             *                  
             * Return Type      : Integer
             * 
             * Return Value     : 0 for success, -1 for failure
             * 
             * Revision History
             * Date       : Author                    : Reason/Change
             * ---------- : ------------------------- : ------------------------------
             * 03/05/2009 : Chris Gendreau            : Initial Creation 
             * 12/10/2009 : Chris Gendreau            : Added HideNotFoundError option
            ************************************************************************/

            Ranorex.Button HDbutton;
            int error = 0;

            //Search for the PushButton on the Form
            try
            {
                RanorexFormName.EnsureVisible();
                RanorexFormName.Activate();
                Thread.Sleep(500);
                HDbutton = RanorexFormName.FindSingle(".//button[@controlname='" + PushButtonName + "' or @text='" + PushButtonName + "']", 60000);
            }

            catch (RanorexException e)
            {
                if (boolHideNotFoundError != true)
                {
                    Report.Error("Unable to find PushButton: " + PushButtonName);
                    Report.Error(e.ToString());
                    Report.Screenshot();
                }
                error = -1;
                return error;
            }

            //Click a PushButton
            try
            {
                Report.Debug("Clicking PushButton: " + PushButtonName);
                HDbutton.Focus();
                Thread.Sleep(500);
                HDbutton.Click(Location.Center);
                Report.Debug("  Clicked PushButton: " + PushButtonName);
            }

            catch (RanorexException e)
            {
                Report.Error(e.ToString());
                Report.Screenshot();
                error = -1;
            }
            return error;
        } //End PushButtonClick
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!

Ciege...

afrosteve
Posts: 17
Joined: Mon Feb 22, 2010 10:59 pm

Re: Dealing with the changing GUI of the test application

Post by afrosteve » Wed Mar 17, 2010 10:44 pm

Ciege, you definitely have a better understanding of the RXPath then I do and have already been a huge help!

To clarify, you're using the RXPath axes './/' to search the entire subtree for the button matching your text string. Do I understand this correctly?

If you don't mind my asking, what does your framework look like? I'm not looking for code samples, but just a general high level overview would be interesting to see.

Do you cache RXPaths at all to save yourself from searching each time?

Thanks again for your help! Reading your code sample was very enlightening.

Regards,
Steve

User avatar
Ciege
Ranorex Guru
Posts: 1335
Joined: Thu Oct 16, 2008 6:46 pm
Location: Arizona, USA

Re: Dealing with the changing GUI of the test application

Post by Ciege » Wed Mar 17, 2010 11:31 pm

Yes, the .// means search from the object down. In my example my parent object is a Form object so I am searching from the form down. You could substitute most any other object. I.e. if you already know your container object you can search from the Container down. Etc...

As for the design of my framework. It is a large collection of reusable methods like the one I posted above. I have various methods that allow me to enter text into a text box to select a combo box item, etc... I also have DOM methods for interacting with IE and the DOM object. These are all collections of methods that are AUT unspecific that I can use again and again from multiple different tests without having to rewrite them every time. Also, if I find a bug or need an enhancement I only need to make the fix/change in one place and it propagates to everyone using it automatically.

I do not cache anything. I always search new at runtime. This does have a drawback of being slower at times as you have stated although it is usually negligible. Consider that much of your automated testing occurs at night, on weekends or on virtual machines that you aren't even looking at and that search time means most nothing. The benefits for me far outweigh the timing. This is completely portable... I can move to any (supported) OS without needing to change my Repo and I do not need to rebuild my repo if/when the GUI of the AUT changes.

All that being said... The repo is a great thing for a centralized management location of all the objects in your AUT. I chose to go a different direction since I "grew up" using automation tools that did not have a repo so I learned my method that works for me.

Feel free to ask me anything. I will do my best to give you *my* way of doing things. Note, my way is most definitely not always the best way of doing things!!! :-)
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!

Ciege...

afrosteve
Posts: 17
Joined: Mon Feb 22, 2010 10:59 pm

Re: Dealing with the changing GUI of the test application

Post by afrosteve » Thu Mar 18, 2010 2:58 pm

Thank you Ciege for sharing your framework design. It's interesting to see how you arranged it.

Even if your way is not the "best" way, it's great to get different perspectives. I'm still new to the automation game, so getting new ideas is a big help.

Would it be ok if I PM'd you on this board?

Also, do you have any opinion on the Ranorex Validate methods? Or do you prefer rolling your own?

Thanks again!

Regards,
Steve

User avatar
Ciege
Ranorex Guru
Posts: 1335
Joined: Thu Oct 16, 2008 6:46 pm
Location: Arizona, USA

Re: Dealing with the changing GUI of the test application

Post by Ciege » Thu Mar 18, 2010 3:49 pm

Sure, PM away... But I would ask that more general questions be in the forum so other users may get the benefit of any knowledge that is transferred.

I think the Ranorex Validate methods are a good basis for doing some basic validation. However, most of my validation is "roll you own" since I can add specific information to the log that I want and I may need to do data manipulation before validation.

Don't worry too much about being new to automation. I was there once. My suggestion is to read a lot and ask a lot of questions (although I do highly recommend trying before blatantly asking for someone else to do your work for you if you know what I mean - trying and failing is a better learning method than not trying at all). We are all on a learning curve and no one person knows it all. I have learned a lot on this forum as there are some very sharp people here!
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!

Ciege...

atom
Posts: 357
Joined: Sun Dec 07, 2008 11:14 pm
Location: Dublin, Ireland

Re: Dealing with the changing GUI of the test application

Post by atom » Tue Mar 23, 2010 6:02 pm

Hiya

We dont use the ranorex repository either, but use a home-grown xml file format to store ranorex xpath's
All our Xpath's are relative to the active window, and not absolute paths
Therefore we always use

<activewindow>.FindSingle(of ...)("descendant::" & <path>)

Where <path> comes from our xml file.

e.g. xml file has format:

<guimap>
<window name="Login">
<element name="User" path="textbox[@controlid='103']" />
<element name="Password" path="textbox[@controlid='104'" />
</window>
</guimap>

We give each window in the application Name, and each gui control inside the window a Name
From those two names, we can return the Path which is relative to the containing window