Page class gets friends

In my previous blog post I explained how you can use the new Page class in your code. Having this class available did spark some new ideas in the community. And again Jeff Brown offered some hours of sleep to make your page classes even more terse by introducing the FindByAttribute. Another new attribute is the DescriptionAttribute.

FindByAttribute

The FindByAttribute can be used on Fields and Properties and gives you a declarative style of expressing how an element should be found. In the following example the GoogleSearchPage is revamped and makes use of the new FindByAttribute.

Note that I only changed the GoogleSearchPage class and didn't have to change the test. And yes indeed, no actual c# code is needed and it almost reads like a real sentence. If only we could get ride of the syntax overhead like the [()] public:

FindBy Name q TextField SearchCriteria

And there is more

Talking about readability, Daaron Dwyer suggested to add a DescriptionAttribute. This new attribute sets the (also new) Description property of an Element or Control instance. This description is set on the element when a page object gets instantiated. With the description you can give the element a meaningful name which will show up in the log WatiN can create (see the Logger class in WatiN). The description will also be used when ToString() is called on an Element or Control.

If you like to have a look at these brand new features then go and get the source from the SourceForce code repository. If you are a little less adventures today, just wait until the next WatiN 2.0 release.

Introducing the Page class

When you create your first automated tests with WatiN you are happy with the results and how easy it is to create tests (at least that is what I keep hearing). Your happily copying and pasting code to find elements into new tests. While your test suite is growing rapidly, changes are made to the web pages and all of a sudden you are in a test code maintenance nightmare. You have created WET code (!= DRY). The solution: separate your test code in tests classes, page classes and control classes (more on controls in another post). So lets start mopping!

Richard Griffin, James Avery and Ayende Rahien all wrote about the problems they were having and the page model they developed. Bruce McLeod even posted the WatiN Jobsite Sample on CodePlex to show you his page model in action. Thanks to the work of Jeff Brown, WatiN 2.0 beta 1 now comes with its own page model. The basic idea of a page model is that each web page in the web site under test has a page class counterpart in the test suite. These page classes expose elements through properties and actions through methods. The result makes it much easier to create new tests and to maintain your test code when changes happen to your web site.In this post I’ll transform the Hello world example of web test automation, as shown on the WatiN homepage, into a test using such a page class.

First a new class needs to be created inheriting the WatiN.Core.Page class, lets call it GoogleSearchPage. This page class exposes properties for the searchcriteria field and the search button. After re-writing the “Hello world example” using the GoogleSearchPage class, the code looks like this (and of course you would put the GoogleSearchPage class in its own file/assembly in production code, but for this example I kept them together).

The Page<> method on the Browser class provides an easy way to instantiate page classes and it does inject the Browser Document into the page class. Because the GoogleSearchPage inherits the new WatiN.Core.Page class, it can access to Document property exposed by the Page class to find elements on the page.

Since the GoogleSearchPage has properties exposing the SearchCriteria textfield and the Search button, all logic to find these controls is held in one place and can be easily reused in other tests. Also notice how the test got much more readable compared to the example on the WatiN website.

Ok, so we have modeled the page with its elements, lets take it one step further. Most web pages offer users one or more actions they can perform on the page. Modeling these actions as methods on your page class would encapsulate even more logic into one place and thus making it easier to maintain when changes happen to the web page. So let me add the method SearchFor to the GoogleSearchPage. Also see how it improves the readability of the test, again.

At this point, when I would navigate to http://www.bing.com and use the GoogleSearchPage, nothing would alarm me that the current page can’t be automated with the GoogleSearchPage class. Instead an ElementNotFoundException would be throw when trying to find an input element with the name btnG (in the SearchCriteria property).

The new Page class offers you some ways to validate the current page before accessing elements on the page. The easiest way is to decorate a page class with the new PageAttribute. This attribute exposes a property UrlRegex which accepts a regular expression. This is used to match with the current browsers Url every time the Page.Document property is accessed. WatiN will check if the browser is still on the correct page and if not, throw a meaningful exception.

If the regular expressions are not your thing or you want to check against another aspect of your page (for instance the title), you can also override the Page.VerifyDocumentProperties method and implement your own check and not use the PageAttribute.

Wel that’s it about the new Page class in WatiN 2.0 beta 1. I hope it will help you to better structure your page model. Following our revamped Hello world example of web test automation.

Technorati Tags: WatiN

WatiN How To screen cast

I have been thinking for a while about creating a How To screen casts series about WatiN. Last week I sat down and experimented a bit with Jing by TechSmith (the creators of CamtasiaStudio).

With Jing it really is very easy to get started with recording and not falling into the trap of creating the visually perfect video with Camtasia. Which, at the end, never gets done. I also like the 5 minute constraint that Jing enforces. This really makes you to focus on the core of things you want to example or show. And last but not least, they offer a 2 GB free storage on screencast.com to host your videos.

For this How To trial episode I used this blog about adding your own elements to WatiN. Let me know what you think about it? Do you like the length, the amount of information, should I do more like these and which topics would you like to be explained?

Watch the episode.

Technorati Tags: WatiN

Introducing the DialogHandlerHelper

Many questions on the watin-users mailinglist (and about WatiN in general) are about handling dialogs with WatiN. WatiN has build in support for handling many of Internet Explorers dailogs but it is hard to find out which DialogHandler is the right one for the job.

WatiN 2.0 beta 1 introduced the new DialogHandlerHelper class. DialogHandlerHelper can be used to investigate which DialogHandler can be used for a specific dialog. The following example shows you how to use the DialogHandlerHelper .

Lets walk through the example. First it creates an IE instance and navigates to a page. Then an instance of DialogHandlerHelper is created and registered with the DialogWatcher. A button is clicked which shows a dialog. The DialogHandlerHelper will now inspect the dialog and close it. Finally the CandidateDialogHandlers are written to the console window for you to inspect and create your final solution.

For this example that would be:

 

Just a thought

To make it even more simple, wouldn’t it be great if someone combined the following into a windows forms app:

• http://www.codeproject.com/KB/dialog/FindWindow.aspx: To let the user point at the dialog that needs to be automated.
• The code inside DialogHandlerHelper to inspect the chosen dialog and find candidate dailoghandlers.
• And, when a Dialoghandler is available for the dialog, uses the the class documentation that comes with the dialoghandler to show you example code about using that specific dialoghandler.

Volunteers?

Technorati Tags: WatiN

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