One of the more interesting and less documented features of VSTS is how to handle the ever changing port of your local development server when running unit tests. This really becomes an issue when you want to write WatiN tests that can run out of the box on any developers machine or a server that is performing continuous integration.

As part of this week’s Teched, Mitch Denny has organized a Smith Family community project to develop an application for the smith family. My contribution was to port WatiN to .net 2.0 (again), so it didn’t have my recent enhancements.

The next step was to write a test that used WatiN, but would work with the TFS continuous integration tool Chris Burrows, without a hardcoded test server. Whilst not the exact code, Chris showed me how to utilise the AspNetDevelopmentServer attribute from the Microsoft.VisualStudio.TestTools.UnitTesting.Web namespace to work with the local ASP.NET Development web server. I have written up a short example below that shows how it is done.

using Microsoft.VisualStudio.TestTools.UnitTesting;
using Microsoft.VisualStudio.TestTools.UnitTesting.Web;
using WatiN.Core;

[TestClass] public class UnitTest1 { private TestContext m_testContext; public TestContext TestContext { get { return m_testContext; } set { m_testContext = value; } }

public string DevServerURL
{
    get
    {
        Uri webServer = m_testContext.Properties["AspNetDevelopmentServer.localhost"] as Uri;
        return webServer.AbsoluteUri;
    }
}

[TestMethod]
[AspNetDevelopmentServer("localhost", @"C:\Docu ... \WebSite1")]
public void TestMethod1()
{
    using (IE ie = new IE(DevServerURL))
    {
        Assert.IsTrue(ie.MainDocument.ContainsText("This is a test."));
    }
}

}
To make this work you will need to add a COM reference to Microsoft Internet Controls, and a reference to your Watin.Core.dll. To our complete surprise, once we had defined the initial test as part of the team build, it ran first go on the server, sight unseen and passed.

Well after a week or so of not touching WatiN, I had another crack at getting authentication to work. In the short term I have abandoned the “technically correct” solution of trying to get impersonation to work, and instead I have ported over the AutoIT code from watir. To do this I created two new classes AutoIT and AutoItLogonParamaters. The main methods in the AutoIT class are:

public void logon(AutoITLogonParameters loginParamaters)
{
     autoit.WinWait(loginParamaters.windowTitle, "", _timeout);
     autoit.WinActivate(loginParamaters.windowTitle, "");
     autoit.Send(loginParamaters.userName, 0);
     autoit.Send("{TAB}", 0);
     autoit.Send(loginParamaters.password, 0);
     autoit.Send("{ENTER}", 0);
}

The logon parameters class just contains properties to get and set three strings so I can pass in one parameter instead of three. The next trick was to work out how to get this code to work on another thread. This required “drilling a hole” through the IE class, passing the login paramaters class into the popupwatcher class and adding the following to the MyEnumThreadWindowsProc method.

private bool MyEnumThreadWindowsProc(IntPtr hwnd, IntPtr lParam)
{
   if (IsDialog(hwnd))
   {

    IntPtr handleToDialogText = NativeMethods.GetDlgItem(hwnd, 0xFFFF);
        string alertMessage = GetText(handleToDialogText);
        alertQueue.Enqueue(alertMessage);

    // get the window title, and check if it matches our login window
    if (GetText(hwnd).StartsWith("Connect to"))
    {
        if (logonParameters != null)
        {
            //  TODO: We should be able to use win32 for all this like
            //  NativeMethods.SetWindowText(hwnd, "Hello");
            WatiN.Core.AutoIT auto = new AutoIT();
            auto.logon(logonParameters);
        }
        else
        {
            throw new MissingFieldException("A window title is missing.");
        }
    }
    NativeMethods.SendMessage(hwnd, NativeMethods.WM_CLOSE, 0, 0);

} return true; } This works exactly as I expected and the following test passed with no problem.

IE ie = new IE(new AutoITLogonParameters("Connect to localhost", "uid", "pwd"));
ie.GoTo("http://localhost");
Assert.IsTrue(ie.ContainsText("this is a test"), "Text not found");
ie.Close();

The main problem with this approach is that it requires the AutoIT dll to be bundled with the code, and it needs to be registered on the machine before it can be used. My next step is to investigate the Win32 calls similar to what already exists to close the popup windows, removing the need for AutoIT entirely.

In my previous post I mentioned that further investigation was required to refine the script to remove the thread.sleep statements. Well post investigation I can share some insights on exactly what is happening and what changes are required.

In addition to the ReadyState property, Internet Explorer exposes a Busy property as well. When a normal page has completed loading the ReadyState will return READYSTATE_COMPLETE and Busy will return false. Internally WatiN uses this to let the browser to dictate when the test script should continue through the Wie.aitForComplete method. This method internally calls two private methods WaitWhileIEBusy() and WaitWhileIEStateNotComplete(). These methods wait for their corresponding methods to return the expected value, then the script continues.

The challenge comes in when a dialog is displayed. When a modal dialog is displayed, IE set’s ie.busy = true, and returns READYSTATE_COMPLETE. If a test is calling WaitForComplete, then the script will hang forever. WatiN caters for this with the WaitForComplete method on it’s HTMLDialog class, which ignores the busy property. Armed with this information, our script now looks like this.

 [TestMethod]
 public void AddNewUser()
 {
    using (IE ie = new IE(baseURL))
    {
        // Click on the 'Manage customers' button to open the customer 
        // management screen 
        ie.MainDocument.Button(Find.ByName(btnManageCustomers)).Click();

        // Click on the add customer image button (an INPUT tag with type image)
        // We need to use ClickNoWait as the Create customer dialog is a modal dialog
        // and the readystate does not return to complete until the dialog is closed. 
        ie.MainDocument.Input(Find.ById(btnSelectTicketType_id)).ClickNoWait();

        // Find the new 'Create new customer' dialog that opens in the collection
        // of dialogs and wait a maximum of 2 seconds for the dialog
        HtmlDialog dialog = ie.HtmlDialog(Find.ByTitle("Select ticket type"),2);

        // Select Melbourne, Qantas and Business class
        // We need the dialog.WaitForComplete() as these contols load dynamically based on 
        // the previous selection and we are in dialog mode 
        dialog.MainDocument.SelectList(Find.ById(ddlDestination_Id)).Select("Melbourne");
        dialog.WaitForComplete();
        dialog.MainDocument.SelectList(Find.ById(ddlCustomerAirline_Id)).Select("Qantas") ;
        dialog.WaitForComplete();
        dialog.MainDocument.SelectList(Find.ById(ddlCustomerClass_Id)).Select("Business");
        dialog.WaitForComplete();
        dialog.MainDocument.Button(Find.ById(btnOk_Id)).ClickNoWait();
        ie.WaitForComplete();

        // Test that the text 'Melboune' is in the page
        Assert.IsTrue(ie.MainDocument.ContainsText("Melbourne"));


        // Test that the text 'Qantas' is in the page
        Assert.IsTrue(ie.MainDocument.ContainsText("Qantas"));

        // Test that the text 'Business class' is in the page
        Assert.IsTrue(ie.MainDocument.ContainsText("Business class"));
    }