This project is read-only.

Speeding up White for programs with large UIs

Jul 26, 2010 at 5:25 AM

I’ve been testing out White for use testing our product which is a fairly large executable with associated DLLs, creating a single desktop window with a number of MDI children. I’ve found White excellent in all ways except one, performance.

For my purposes, White is unacceptably slow & I've tracked the speed issue to the repeated depth first searching. Our menu has around 1500 items and takes 40 seconds for White to build the hierarchy on my desktop PC, this made avoiding multiple parses of the Menu vital, but we also have a lot of MDI child windows with large numbers of controls which could help slow down the testing.

I looked at the work-around (This issue and Threads 49778 & 77934) and starting building a test harness based on information from there, but was still encountering performance below what I needed and I've also considered using the ability to control White's search depth, but that doesn't work very well for me as while at the top level, finding and caching the static children and MDI owner and then explicitly searching the MDI owner for the desired children works well, within individual windows it is handy to be able to be able to do depth first searches within individual MDI children.

My initial approach to solving with problem was to create additional methods called “Child” and “Children” to complement the existing Descendant / Descendants methods. I’ve also created FindChildren / GetChildren / GetMultiple children methods for symmetry and added MdiChild to the Panel class. The difference between the Child /Children methods and the Descendant / Descendants methods is that the Child methods only search the immediate children of the base object, so are faster. Not being aware that the issue there was fixed I attached this as a patch to the now closed work item 4638.

Is there an official fix to my problem already in White that will allow switching back and forward between depth first and shallow searching? If so, can someone point me at it; if there isn't what's the best way to go about submitting my patch?

Many thanks



Aug 6, 2010 at 6:21 PM
Oct 11, 2010 at 3:46 AM
Edited Oct 11, 2010 at 3:47 AM

Thanks, that works nicely for me.

Unfortunately when I try and get MDI children from the window I hit the slow performance again. This seems to be because the menu is at the same level as I need to search to find the MDI children. Copying the 'MdiChild(SearchCriteria searchCriteria)' method from the Window class to the Panel class in Panel.cs lets me cache the MDI Owner & query it for the desired child.

Is it possible to have this change added into White please?

In Core/UIItems/Panel.cs After the existing "using" declarations:


 using White.Core.AutomationElementSearch;
using White.Core.Factory;
using White.Core.UIItems.Finders;


... at end, after  "Text" :

        /// <summary>
        /// Returns a UIItemContainer using which other sub-ui items can be retrieved.
        /// Since there is no single standard identification for MdiChild windows, hence it is has been left open for user.
        /// </summary>
        /// <param name="searchCriteria"></param>
        /// <returns></returns>
        public virtual UIItemContainer MdiChild(SearchCriteria searchCriteria)
            var finder = new AutomationElementFinder(automationElement);
            AutomationElement element = finder.Descendant(searchCriteria.AutomationCondition);
            return element == null ? null : new UIItemContainer(element, this, InitializeOption.NoCache, windowSession);