Wednesday, July 24, 2013

A Basic example of web site automation with TestStack.White

TestStack.White is an ancestor of old White UI Automation framework. The framework installs easily from NuGet.

To automate the web browser, we need to launch it and then automate the UI using White’s API. There are two ways to automate an application in white:

  • we can use the API to find controls in the control hierarchy and then use the API of found control to automate it (for example, the TextBox class that corresponds to input fields has the Text property with two accessors, get and set)
  • we can use the API to move the mouse and input data from the keyboard

The first method, although sounds interesting, is rather difficult when automating a web browser. The problem is that the White search API is rather limited and works better if the underlying application is a .NET application. For example, any control on the screen can be found by its .NET “name”.

In case of a native application (and browsers are not .NET applications), the only way to find a specific control is to get a complete list of controls and try to find a match programmatically. And this is why it is easier said than done. For example, trying to automate the google.com web site and searching for all visible textboxes on FireFox yields a list of 42 controls with no way of picking this correct one that should contain the search phrase.

Let’s then see the code snippet and discuss it:

var psi = new ProcessStartInfo 
{ 
    FileName  = "iexplore.exe", 
    //FileName  = "firefox.exe",
    Arguments = "http://www.google.pl" 
};
 
Application application = Application.Launch( psi );
application.WaitWhileBusy();
 
Window window = application.GetWindows().FirstOrDefault();
 
application.WaitWhileBusy();
 
// find control and input text ...
//IUIItem[] textBoxes = window.GetMultiple( 
//   SearchCriteria.ByControlType( System.Windows.Automation.ControlType.Edit ) );
//TextBox searchTextBox = textBoxes[1] as TextBox;
//if ( searchTextBox != null )
//    searchTextBox.Text = "search phrase";
 
// .. or rather simulate user input
window.Keyboard.Enter( "search phrase" );
 
window.Keyboard.PressSpecialKey( White.Core.WindowsAPI.KeyboardInput.SpecialKeys.RETURN );
 
//window.Mouse.Location = new Point( 800, 870 );
//window.Mouse.Click();

As you can see it all starts with lauching the web browser’s process. Then I am selecting the very first active window of the process and this is where things start to be messy – this works only if there are no other active instances of the same browser.

Then the commented out snippet shows how to use the API to find a text box and set its value but then it turns out that providing the input is easier if made with the Keyboard and/or Mouse objects.

Wednesday, July 10, 2013

Debugging the source code of third party components (NHibernate and others)

The .NET framework source code debugging has been received as one of the most impressive features of VS2008. Sadly, although many detailed instructions has been published (here, here, here and dozen of other web pages) it just doesn’t work.

There are probably multiple reasons for this, including the out-of-sync versions of base class libraries. People complain, open issues on Connect, ask on Stackoverflow, all this for nothing.

My initial attempt on this with VS2012 and .NET 4.5 was succesfull. I was able to debug into Console.WriteLine and other library methods and I’ve found this amazing. I think it worked for few hours and then stopped working and despite all my attempts, prayers and curses it just doesn’t work anymore.

What seems to work however, is the Symbol Source, they publish *.pdbs for multiple NuGet packages including NHibernate, Autofac, Castle or ServiceStack.

What you get then is when you register their source server in VS (follow this tutorial but point to http://srv.symbolsource.org/pdb/Public as described here), you can debug the internals of all these 3rd party components. Works like a charm.