Anyone that has done any serious test automation of ASP.NET applications knows that .NET is a tad verbose when it comes to the control names that it generates. ASP.NET generates its control ID’s based on a hierarchy of controls. For example, if you have a textbox inside a user control that is placed in side a placeholder, the of name property of the control will be something like name=”ctl00$ContentPlaceHolderMain$UserConrol1$txtLogin”. On some applications I test, I have seen control ID’s 130+ characters in length. This presents an interesting challenge to the automator where your scripts can easily become something like this:

There are two scenarios that we want to be able to easily handle to maximise script maintainability. Firstly, if the control is renamed, we only want to have to change the control in one place. Second, if the hierarchy of the controls is changed, (or if the control moves in the page) we want to be able to handle it easily.

One of the new features introduced into version 0.8 of WatiN is support for using regular expressions. This provides a extremely powerful way of solving both problems.

The first thing we will do is define a static class that returns the name property of the control. If this control was being used to test, say Amazon.com, I would structure the class that uses a namespace structure that allows the use of intellisense to help find controls at design time.

using System;

namespace Amazon
{
    class LoginPage
    {
        public static string txtLogin = "ctl00$ContentPlaceHolderMain$UserConrol1$txtLogin";
    }
}

This allows the test script to be simplified as follows:

Ok problem one solved, and now that we have our class, we can easily change it to use the regular expression support. If we want to ignore the whole control hierarchy and only match the control name txtLogin, then we can use an expression like:

[a-zA-Z0-9\$]*txtLogin

(If like me, you can never remember what the expression should be, I can highly recommend regexlib.com, which contains examples, reference sheets and a regex tester.) WatiN implements overloads in Find.ByName and can consume the control name as either a string or a Regex. This allows us to use the regular expressions by only changing how the control is defined in the class. An updated version of the class using regular expressions is as follows:

using System;
using System.Text.RegularExpressions;

namespace Amazon
{
    class LoginPage
    {
        public static Regex txtLogin = new Regex("[a-zA-Z0-9\$]*txtLogin");
    }
}

Now the only thing that will cause us problems is if the txtLogin control us renamed, or another txtLogin control is added to the page somewhere else. But what are the chances of that happening …

Scott Hanselman has blogged about his tolerence for vista induced pain. I am running Vista RC1 on the Sony Vaio that I use day-to-day and, and although I have had my share of pain, specifically around USB induced blue screens, my overall impression is quite positive. One key difference I think is that the Vaio was only purchased a couple of months ago.

On reading scott’s post however my reaction was, how cool is the reliability monitor! This is something that every appicaiton needs.



If you are trying to find it, it is part of computer management.

Whilst researching a solution to get WatiN running under Vista RC1 with UAC enabled as discussed in a earlier post, I came across Daniel Moth’s blog. Daniel is a Microsoft UK Developer Evangelist who is focusing on the new stuff in Vista. He has two good posts that I would consider required reading:

Vista: User Account Control; this post covers what you need to do programmatically for your application to take advantage of

I have spent the evening debugging WatiN on Vista RC1, and I have uncovered the following issues:

1. Your test tool of choice must be run as administrator.

If you are using nunit or VSTS to run your tests you MUST run them as administrator. If you don’t then a second process is spawned in the ie.goto function when Internet explorer’s Navigate function is called. The second process will then go where you told it, and the original process will just hang and never load.

2. Finding IE by title doesn’t work as expected.

The AttachToIEByPartialTitleAndByUrl unit test fails. On further digging this one get’s interesting. If you launch a browser window, and point it to www.google.com, the test will fail because it finds the window as expected. However when WatiN opens a window itself and points it to google the same comparison fails. The problem is that in FindIE, the following line.

ShellWindows allBrowsers = new ShellWindows();

Does not return the ie windows that WatiN has created, as expected. A solution here may be to replace that

Jeroen van Menen has released WatiN 0.8.4. This new version includes several bugfixes, simpler syntax and a .net 2.0 version out of the box. Full release notes are here, and you can download the .net 2.0 verison here.

Looking forwards to version 0.9, you can expect support for authenticaton and improved dialog handling.