Unintelligible

Tuesday, July 28, 2009

Installing Selenium-RC as a Windows service

Installing Selenium as a Windows service is reasonably straightforward - based on the instructions for Fitnesse, which unfortunately seem to have been deleted from the Fitnesse wiki, but which have been reproduced here.

There are two parts to doing this - the first, registering the service using srvany.exe (which wraps any executable as a service), and the second, adding the keys to the registry to tell srvany.exe how to launch Selenium-RC. srvany.exe is a part of the Windows Resource Kit, if you don’t have it already you will need to download it from Microsoft.

The following will register the Selenium service - on the command line (all in one line):

"C:\Program Files\Windows Resource Kits\Tools\instsrv.exe" SeleniumRC
"C:\Program Files\Windows Resource Kits\Tools\srvany.exe" -a [myuser] -p [mypass]

This is assuming the Windows Resource Kit has been installed to its default location, “C:\Program Files\Windows Resource Kits”. Also, note that the user supplied needs to have the Log On As Service permissions assigned.

Now, add the following keys to the registry - this text can simply be copied-and-pasted to a .reg file, then double-clicked to add the entries to the registry:

Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SeleniumRC\Parameters]
"Application"="java.exe"
"AppDirectory"="C:\\Program Files\\selenium-server-1.0.1"
"AppParameters"="-Xrs -jar selenium-server.jar"

You should now be able to start the service - if you get an error about the service failing to start due to a logon issue, make sure that the user you are using to run the service has been granted Log On As A Service permission (editing the service logon credentials in the Services MMC snap-in and saving the changes will cause this to happen automatically.)

posted by Nick at 10:08 pm - filed in testing, windows  

Friday, May 4, 2007

Using WatiN to automate accessibility testing in .Net

WatiN is a web testing framework for .Net - it is a C# port of Watir, which is in Ruby. Both function by driving Internet Explorer and are fully scriptable, which means you can do things like:

[Test]
public void SearchForWatiNOnGoogle()
{
    using (IE ie = new IE("http://www.google.com"))
    {
        ie.TextField(Find.ByName("q")).TypeText("WatiN");
        ie.Button(Find.ByName("btnG")).Click();
        Assert.IsTrue(ie.ContainsText("WatiN"));
    }
}

This is from the WatiN documentation page, which is pretty helpful - as this shows, it’s easy to get started, and writing basic tests is straightforward (although perhaps not as fast as the Ruby version). WatiN also integrates well with NUnit and other testing frameworks (including TestDriven.Net and the Visual Studio 2005 test runner). I’ve been using this at work to run some basic accessibility tests on some of our web-based products; although accessibility testing can’t be completely automated, it’s pretty handy to be able to perform repetitive HTML inspections automatically. This checks that all <img> tags on a page have the required “alt” attribute (required in the WCAG 1.0 guidelines on images):

[Test]
public void CheckAllImagesHaveAltAttributes()
{
    using (IE ie = new IE("http://localhost/test.aspx"))
    {
        foreach (Image img in ie.Images)
            if (img.Alt == null || img.Alt.Trim().Length == 0)
                Assert.Fail(
                    String.Format("The image with id '{0}' "
                    + "and src '{1}' doesn't have a alt tag "
                    + "in '{2}'",
                    img.Id, img.Src, ie.Url)
                );
    }
}

This checks that all links on a page have a “title” attribute (an overly strict interpretation of the WCAG 1.0 guidelines on links):

[Test]
public void CheckAllLinksHaveTitleAttributes()
{
    using (IE ie = new IE("http://localhost/test.aspx"))
    {
        foreach (Link link in ie.Links)
            if (link.Title == null || link.Title.Trim().Length == 0)
                Assert.Fail(
                    String.Format("The link with id '{0}' "
                    + "and text '{1}' doesn't have a title tag "
                    + "in '{2}'",
                    link.Id, link.InnerHtml, ie.Url)
                );
    }
}

Or that all input fields in a form have an associated “label” tag (WCAG 1.0 guidelines on form labels):

delegate void TestInputFor(IE ie, Element inputField);
 
[Test]
public void CheckAllFormFieldsHaveLabels()
{
    using (IE ie = new IE("http://localhost/test.aspx"))
    {
        TestInputFor assertElementHasLabel =
            delegate(IE ieInstance, Element inputField)
        {
            //check whether the corresponding label exists.
            Debug.WriteLine("Checking whether element "
                + inputField.Id + " has a label");
            int cnt = 0;
            foreach (Label lbl in ieInstance.Labels)
                if (lbl.For.Equals(inputField.Id))
                    cnt++;
            //assert the label was found
            Assert.AreEqual(1, cnt,
                String.Format("Expected a label for text field"
                + " with ID {0}, but found {1:d} in page '{2}'",
                inputField.Id, cnt, ieInstance.Url));
        };
 
        foreach (CheckBox cb in ie.CheckBoxes)
        {
            assertElementHasLabel(ie, cb);
        }
 
        foreach (TextField tf in ie.TextFields)
        {
            if(tf.GetAttributeValue("type").Equals("hidden"))
                continue;
            assertElementHasLabel(ie, tf);
        }
 
        foreach (SelectList sl in ie.SelectLists)
        {
            assertElementHasLabel(ie, sl);
        }
 
        foreach (RadioButton rb in ie.RadioButtons)
        {
            assertElementHasLabel(ie, rb);
        }
    }
}

These are rather basic tests; and they are far from extensive. However, they should give a good idea how much time can be saved by automated testing, especially in the context of standard systems which get customised on a per-client basis (e.g. a content management system for which the layout is customised on a per-client basis; the tests are written once and can be run against each client’s version).

posted by Nick at 8:00 pm - filed in .net, accessibility, testing