Reusing an IE instance in VS test

I was going over the WatiN questions on stackoverflow. One of the questions involved reusing an IE instance over multiple tests. Since Visual Studio’s test runner creates a new Thread for each TestMethod in a TestClass you get a nasty InvalidComObjectException with the additional information "COM object that has been separated from its underlying RCW can not be used.".

Following the problem example as posted on stackoverflow. When running these tests, the first test “testOne” passes but the second test “testTwo” will throw the InvalidComObjectException.

Does this mean we can’t reuse an IE instance across multiple tests? Nope.

We can still instantiate IE in the method decorated with the ClassInitialize attribute but in each test case we need to attach to the running instance using IE.AttachToIE(constraint). To find the Internet Explorer instance we created, we can use the window handle to find the instance. Somewhat like a “good-old-pointer”. Add a little bit logic to cache the found IE instance and return this as long as the CurrentThread hasn’t changed and the helper class could look something like this:

To make use of this helper class, we create an instance of IEStaticInstanceHelper and assign it to a static field (as we did before with the IE instance). Next we assign an IE instance to the IE property. Now we can use this Internet Explorer instance in our test cases without bothering about different Threads.

For clarity sake I wrapped the call to the  ieStaticInstanceHelper.IE property in an instance property of the test class, called IE. And to make sure the IE instance gets closed after all tests have run I added a method decorated with the ClassCleanup attribute.

 

Off course you could create a base class which is used by all your test classes, but that's up to you.

You can download the code here.

Happy testing with WatiN and Visual Studio test runner!

Technorati Tags: WatiN

Released WatiN 2.0 beta 1

I’m very happy to announce the release of WatiN 2.0 beta 1!

It has been a long ride from the first CTP release to this beta release. This has mainly to do with the beta having a completely different architecture from the previous CTP releases. With the CTP releases we used interface like ITextField etc. to provide support for multiple browsers. This resulted basically in creating a complete new set of about 50 classes for each additional browser we wanted to support. With this release we have managed to reduce this amount to 6 classes for each additional browser.

Another big change is made to the test suite. All the tests that came with WatiN 1.3 and were run against Internet Explorer, making sure every feature worked with IE6 and IE7, are now run against FireFox 2 and 3 and IE8 as well. This ensures that all features have the same behavior across all these browsers.

We are not there yet, that’s why it is still a beta release. We will continue working on WatiN 2.0 to fix the list of known issues and to incorporate community feedback. We intend to do a release at the end of every month, working towards a final release in June or July.

In the coming days I will blog some more about the new features. For now you can read the release notes at http://watin.sourceforge.net/releasenotes-2-0-10-x.html and download the release here.

Happy testing with WatiN!

Technorati Tags: WatiN

Custom elements and controls in WatiN 2.0 beta

Update 3/31/2009: You can download the example code for this blog post here.

Still working on the beta release of WatiN 2.0 (will ship in the next few days), but I felt the need to blog about a new feature in the 2.0 beta. In previous posts I showed you how you could extend WatiN with your own controls:

• Supporting custom elements with WatiN, Part I
• Supporting custom elements with WatiN, Part II
• And part III never made it…

In the upcoming beta WatiN will offer you these new features:

1. Add support for native html elements not provided by WatiN.
2. Add support for your (custom) web controls.

Which make the previous posts obsolete.

Add your own native html element

WatiN doesn’t provide support for all html elements defined by the W3C standards. For instance there is no out-of-the-box support for li tagged elements. But starting with WatiN 2.0 beta 1 you can “add” support for linked lists yourself.

First lets show you how you could make use of your own ListItem element.

ListItem list = browser.ElementOfType<ListItem >(Find.ById(“theElementId”));

(And yes, this syntax also works with the out-of-the-box elements like TextField etc..)

Now we know how we could use a none native ListItem element in our (test) code, lets create this ListItem class.

1. First create a new class called ListItem and make it inherit WatiN.Core.Element.
2. Add the ElementTagAttribute to your class to tell WatiN which tagName(s) your element class can handle. Incase of ListItem: [ElementTag(“li”)]
3. Add whatever properties and methods are needed to make this element work for you.
4. The last thing you need to do is register ListItem with WatiN’s ElementFactory before you can use it in your (test) code:

ElementFactory.RegisterElementType(typeof(ListItem ));

That’s it, you’ve added a new (almost native) element to WatiN. You could make it look even more native by extending the IElementContainer  interface with some extension methods which do wrap the calls to ElementOfType<ListItem >(…) and make it look like:

ListItem list = browser.ListItem (Find.ById(“theElementId”));

Add support for your (custom) web controls

I’ll tell you about that one in my next post… back to releasing the beta :-)

Technorati Tags: WatiN