IETest

IETest is a .NET library for testing web sites through Microsoft Internet Explorer. It enables you to automate Internet Explorer to the point where you can perform automated testing without any human attention required.

IETest is developed by BestBrains Aps, a Danish software development consultancy company specializing in agile methods and test driven development. It is open source, released under the MIT license and hosted on

Other frameworks supply similar functionality: Watir which is Ruby based, and IeUnit which is JavaScript based. IETest is .NET based and supports modeless dialogs.

You can download the latest source code here: ietest-0.2.zip.

Test driven development is a very efficient way of developing code. It is gaining popularity and test tools are ever improving. Automated testing of UI code seems to lack behind a little, though. With good reason - simulating a user is tedious and error prone. Using IETest, testing your ui becomes possible. Like with all software, writing tests for your web applications has a way of automatically making you write better code. You will be more likely to give elements unique and intuitive identifiers and less likely to write hacks that might well work but would be difficult to test. For a thorough discussion about the wonders and challenges of test driven development, take a look at Testdriven.com.

IETest requires the .NET framework version 1.1 or later. IETest is built with C#. So far, it has only been used with C# but using it from other .NET languages should be simple.

As it is more of an automation framework than an actual testing framework, you will also need your favourite testing framework such as NUnit in order to write tests.

The key element in IETest is the IEDriver class. It wraps IE automation functionality and supplies help for various common tasks. The following piece of code will create a new IEDriver which will open Internet Explorer and navigate to Google. Then, it will find the query input box which has the name "q", and enter "BestBrains" in there. Finally, it will locate the search button, named "btnG", and click it. You should see search results popping up just before Internet Explorer closes.

using(IEDriver ie = new IEDriver("http://www.google.com", true))
{
	Input q = ie.MainDocument.FindINPUT("q");
	q.Value = "BestBrains";
	
	InputButton btnG = ie.MainDocument.FindINPUT_BUTTON("btnG");
	btnG.Click();
}

The primary class in IETest is the IEDriver class. Instaitiating this class will cause Internet Explorer to open and navigate to the requested site. From there, you will most likely access the main document through the MainDocument method. This is where all the html is stored.

At the time of writing, IETest has wraps for the following HTML tags:

Most of these have simple Find functions. This means that you can write things like: FindTABLE(elementId), which will locate the table element with the given id.

Sometimes, you simplky don't have an ID of the element you are looking for. Or multiple elements share the same id. In such cases, you have two options when you really want to locate an element. You can search for it by some other means than the id, or you can count your way towards, by traversing the DOM. Currently, IETest has no way of performing non-id based searches, but this is definitely a high priority task. There are however ways to traverse the DOM. Firstly, all elements expose a method called NextSibling. This method will give you the element that immediately follows the current. The Parent() method will give you the element that contains the current. Furthermore, a number of properties give you a way of locating a child of the current element. TBODY, for instance, will give you a collection of TableSection's.

Popups are difficult to test for a number of reasons. Most of all, the IE automation model makes it hard. As far as we can tell, there is no way to access the DOM of a modal IE popup. Therefore, there are some things that simply aren't possible to test. However, if you have access to the code of the web application, changing modal dialogs to modeless dialogs can help out in many situations. There are two problems with this approach: firstly, the modeless dialog doesn't return a result but instead, it returns a handle to the opened window. This can be solved with some JavaScript workarounds. The second problem is that focus is not restricted to the dialog - you can click on the window behind it and continue doing things even though there is a dialog waiting for input. This is actually not a big problem because for testing purposes, you simply won't do that - there should be no user anyway. Controlling modeless dialogs with IETest is simple. Call IEDriver.GetPopupDocument and you have the document object of your popup.

The JavaScript function alert() is quite handy for the web developer. It provides a simple way to give feedback to the user that a form is not filled correctly etc. Often, these alert messages will be essential to what you are testing. Testing a validation function requires being able to know that it found the data invalid. IETest offers a way of testing this. The PopupWatcher is a thread that sits in the background looking for alert windows. When one is encountered, it is stored in a queue. When an alert is expected, call the PopAlert() function which will return a string containing the first popup message that was caught and remove it from the queue. When the PopupWatcher is disposed of (usually together with the disposal of IEDriver), it will complain if there were any messages left in the queue, indicating that an unexpected popup appeared at some point.

As mshtml expects the host to be running as STA - single threaded apartment - you need to make sure your tests are as well. If you're using testdriven.net, you won't have a problem but NUnit-gui runs as MTA per default. Hence, you need to change the threading apartment manually. The self test illustrates how to do this in your TestFixtureSetUp method:

[TestFixtureSetUp]
public void Setup()
{
	System.Threading.Thread.CurrentThread.ApartmentState = System.Threading.ApartmentState.STA;
	
}

IETest was made primarily as an abstraction layer for specialised libraries for testing specific web applications. Hence, classes have been designed to be overridden.

Todo: