1. White introduction
White is an open source tool developed by Microsoft, which provides a framework mainly used for UI testing. It is suitable for WinForm, WPF, Win32 and SWT (java) testing.
White was developed in C#, but in addition to supporting the .Net language, White also supports Python and Ruby. (Python and Ruby are combined with .Net Framework through IronPython or IronRuby as a port.)
White is based on the UIAutomation class library. It calls UIA and encapsulates it, so its structure is like this: the bottom layer is the Windows operating system, and on top of the Windows operating system is the .Net runtime. Above the runtime is UI Automation Library, above UI Automation Library is White, and then the top layer is the test framework that we call White to build. (What is UIA, it is a class library of .Net, it can help us find UI controls, get the attribute values of the controls, and be able to operate the controls. Of course, it is mainly based on the Windows platform.)
Second, White looks for the mechanism of the control
White uses the UI Automation API to find the controls in a window. It finds the specified control by traversing all the controls in the window. So if there are multiple windows open, how do you know which window to look for? This is the case, every time you want to find a control, you must pass in the window handle to which it belongs, so that UIA communicates with the specified window through window message. Then go to the designated window to find the corresponding control.
In fact, White is very similar to selenium, watir and other frameworks. It realizes the identification and operation of windows (controls) through the UIAutomation library and Windows Message. White exposes the corresponding Control information to UI Automation, and then uses the UI Automation library to identify these Control information as UI Items.
White's main ways to find controls are as follows:
l Search by the name of the control
l Find by the AutomationID of the control
l Search through the Text displayed by the control
l Search by the type of control
l Search by index
l Find by location
Among these several ways of searching for controls, if only one is used, the first ones are not very fast, except for the last one to find by location.
Experience:
So is there a way for us to find the speed in advance? I generally use these methods in actual use:
Combine a variety of search methods, for example, provide not only the control type, but also the name or Automation ID. (In this way, UIA can find the controls in a targeted manner instead of looking for them one by one. First, according to the type, you can filter out a large number, and then just find the Auto ID corresponding to the control that matches this type.)
Another method is to find the main control first, and then use the main control to find the control that belongs to the next level of the main control. For example, first obtain the handle of a GroupBox, and then find the specified Name under this GroupBox. In this way, the search range is greatly reduced, and there is no need to search for the full window.
Of course, sometimes White may not be able to find the desired control 100% after traversing it. At this time, we have to set up a loop in our own code. When the judgment returns to null, wait for a second and a half and then let it go. Find it again. Of course, this loop is not unlimited. We give it 10 chances at most. If it still cannot be found, we can only throw an exception or return null.
This problem also occurs when the control is operated, so for the operation of each control, we have to wait until the control is enabled before proceeding.
Three, White finds controls by location
Location search can quickly find the corresponding control, instead of traversing the various controls in the window like other methods. As long as we run the program under test once, White will automatically save the location information of all controls to an XML file, and White can quickly find the specified control when the program under test is run again in the future. The control is that the information is associated with the specified window, so changes in the size and position of the window will not affect the search for the control. Of course, if the design of the interface is changed, the previously saved information has to be rewritten.
Four, element recognition tool, it is convenient for us to provide control information to White.
UISpy is a tool provided by the .Net3.0 SDK and does not belong to the White framework, but we can use this tool to identify elements. UISpy will recognize all elements as a control tree, which can provide detailed information about the control, such as: Name, AutoID, Type, Position and other properties and methods.