Using WatiN to Leverage Common Elements in Web Testing

Ron Palmer, Exception 13, Inc.

What is WatiN?

WatiN is an easy to use, feature rich framework for Web Application Testing in .Net (W.A.T.I.N.). Inspired by and modeled after Watir, the framework has many benefits. It follows an open source model and the compiled libraries plus source can be freely downloaded, utilized and modified from the WatiN page on Sourceforge.net. Not only does it provide an extensible framework but also comes with the knowledge that over 60,000 users have downloaded the framework, making it one of the top 3 of open source web testing applications.

Being inspired by Watir, WatiN shares many of the same concepts and limitations as all WatiX (‘X’ being the language specific version, such as WatiN for .Net, Watir for Ruby or Watij for java) frameworks. It’s important to remember that the ‘X’ not only represents the development environment of the WatiX libraries but also the environment that will be use in the creation of the actual test code. This means that there is no secondary scripting language to master. You only need to be proficient in the language specific to your flavor of WatiX. It’s also important to note that WatiN is browser dependent and only supports automation against Internet Explorer and Firefox. So if you are planning a cross browser testing effort with Safari or Opera requirements, you may want to look into other products.

Unlike many web testing platforms that use HTTP requests to emulate a browser transaction, WatiN operates at the browser object level. This allows for programmatic control of objects within a browser instance and gives the end user the ability to manipulate and exercise properties or methods exposed by the browser. This actual browser interaction allows for more direct testing of dynamic elements such as popup dialogs and AJAX controls. If you happen to be new to WatiN or Watir it is well worth the time to view the ‘Getting Started’ page noted in the Further readings/downloads section of this article.

Even though WatiN is an outstanding framework, even the best frameworks are only as good as their implementations. This article will attempt to provide its reader with some practical insight into creating automation based on the WatiN framework. It will present a well thought out and proven foundation for general web testing. The final structure and format for your tests will vary based upon the unique requirements of your environment.

What are common elements?

There are many common elements on any given web page. These can be standard objects supported by a browser’s Document Object Model or even custom controls provided by a third party. Regardless of the objects origin, most development shops treat common objects across pages in a similar manner. We can use this component of object oriented programming to create a framework that allows us to produce a library that supports objects and their functionality on a page.

Now you are probably asking yourself, "Great, so there are objects on a page. Now how are those objects classified as common elements for a library?" That right there is the billion dollar question (Note: It used to be the million dollar question but I’ve adjusted the value based on inflationary measures and a falling dollar value). Realistically, there is no one way to classify these objects. What matters is that your team defines a logical classification structure for the objects on a page and applied in a consistent manner across a project. In the following examples I will walk you through how I have classified common elements by page, type, and functionality for a simple "Contact" page.

A page is the highest classification of common elements within a site. This classification is a logical grouping of objects combined to make a web page. As you can see on the "Contact" page (Figure 1), there are several types of objects on this page. These include Images, labels, breadcrumbs, links, text fields, select boxes, and a button for this specific page. Keep in mind this is not meant to represent all objects that are possible on any page; just the objects that make up this page. When we build our library for this page you will notice that the page specific class is nothing more than a reference to each of the objects grouped together by its specific type.

Figure

The object type classification is a more broadly defined classification based upon the object types within a site or project. Most projects have a defined GUI specification document or at least a general agreement within the development staff as to what objects are used within a site. This document normally will define acceptable colors, fonts, images, object types, etc. for use on any given page. Using this information we can define all of the object types expected to be used within a site. This will be the foundation for our object type library and will be leveraged as a common library for defining each page class.

The final classification is by object functionality. Each object type has specific functional limitations. For example, a text box on a page may input text, delete text or display text. These are the functional actions associated to that object. Knowing the functional limitations and available actions of an object will allow us to create functions to support each of the functionality points.

How do I leverage these common elements?

Now that you have an idea of what WatiN is and some general concepts in classifying common elements within a page, we need to look at how to leverage these common elements. With our objects grouped in a logical manner, we can produce the code base to support the functionality of each object type. For the purposes of this article let’s focus on a basic web component, the TextBox. When looking at a TextBox we can see that there are basic functional points that are covered by this object in the context of a site. For this site, we will create functions within a TextField class to support SetValue, GetValue, TextFieldExists and ValidateText (Code Sample 1). This will give us a basic level of coverage for functional testing of this page.

Code Sample: Test code for TextField.

namespace EX13.BaseElements { public class TextField { private IE CurWin; private string BrowserTitle = ""; public TextField(string _BrowserTitle) { BrowserTitle = _BrowserTitle; if (BrowserTitle == null) { Assert.Fail("No browser title was passed into BaseElements."); } CurWin = IE.AttachToIE(Find.ByTitle(BrowserTitle)); } public void SetValue(object SE, string Value) { CurWin.TextField(Find.ById(new Regex(SE.ToString()))).TypeText(Value); } public string GetValue(object SE) { string TextValue = CurWin.TextField(Find.ById(new Regex(SE.ToString()))).Value; Assert.IsNotNull(TextValue, "Text.GetValue FAILED: '" + SE.ToString() + "' Returned a null value"); return TextValue; } public void TextFieldExists(object SE, bool checkType) { if (checkType) { Assert.IsTrue(CurWin.TextField(new Regex(SE.ToString())).Exists, SE.ToString() + " Does not Exist"); } else { Assert.IsFalse(CurWin.TextField(new Regex(SE.ToString())).Exists, SE.ToString() + " Shouldn’t exist"); } } public void ValidateText(object SE, string Value) { Assert.AreEqual(CurWin.TextField(new Regex(SE.ToString())).Value, Value); } }

By creating a class to define functions for each functional point of an object type, we create an abstraction layer that allows us the ability to combine common IDE elements like Asserts with the core functionality of WatiN. This library assures that a test method utilizing this class will have a standard set of supported functionality and consistent handling of object specific logic. Not only does this reduce code within the test methods and Page Oriented Libraries but it also reduces implementation complexity.

With the Object Type functionality library built, we can now focus on building Page oriented libraries. The Page oriented libraries are used to define the objects that exist on a given page. We will create a specific class for each page that defines the named objects on that page using enums to list each object by type (Code Sample 2). Each enum value will contain the ids of objects on a page based upon its type classification. For example the page contains three input fields with the ids ‘TextName’, ‘TextEmail’, and ‘TextPostal’. These will be public members of the ContactPage class and will be available to each test method that utilizes the class.

Code Sample: Test code for ContactPage Class.

Leverage the page Libraries to create tests.

Once the Page oriented classes are defined we can begin to leverage these classes with the Object Type functionality to produce well defined test methods. This process is fairly straight forward and provides the tester who is responsible for the creation of the test a finite choice of available objects to write test code against and decouples the test method from the actual page under test. This decoupling reduces the impact of object property and functionality changes within a site.

Code Sample: Test Code for ContactPage Tests.

[TestMethod] public void Assert_ContactPage_Objects() { var ContactWindow = new IE("http://www.test.com/contact.aspx"); Contact ContactScreen = new ContactPage(ContactWindow, "ContactPage"); //Validate List Boxes Exists ContactScreen.selectList.SelectBoxExists(Contact.EnumSelect.SelectReqInfo, true); //Validate Labels Exists and text ContactScreen.label.ValidateLabelText(ContactPage.EnumLabels.LabelWhoYouAre, "Who you are"); ContactScreen.label.ValidateLabelText(ContactPage.EnumLabels.LableName, "Name"); ContactScreen.label.ValidateLabelText(Search.EnumLabels.LabelEmail, "Email address"); ContactScreen.label.ValidateLabelText(Search.EnumLabels.LabelPostalCode, "Postal code"); //Validate Text boxes Exists ContactScreen.textfield.TextFieldExists(ContactPage.EnumTextFld.TextName, true); ContactScreen.textfield.TextFieldExists(ContactPage.EnumTextFld.TextEmail, true); ContactScreen.textfield.TextFieldExists(ContactPage.EnumTextFld.TextPostal, true); //Validate Buttons and Links ContactScreen.link.LinkExists(ContactPage.EnumLinks.LinkDefault, true); ContactScreen.link.LinkExists(ContactPage.EnumLinks.LinkAbout, true); ContactScreen.link.LinkExists(ContactPage.EnumLinks.LinkProducts, true); ContactScreen.link.LinkExists(ContactPage.EnumLinks.LinkAdditionalInfo, true); ContactScreen.link.LinkExists(ContactPage.EnumLinks.LinkSubmit, true); }

All of the source code displayed in this article was produced using Microsoft Visual Studio Team System (VSTS) 2008 Test Edition. If you currently do not have VSTS installed, a trial copy can be downloaded from Microsoft.com (Mandatory disclaimer: The author of this article is not a MS ideologue… Really, I swear. Some of my best friends work on Java projects. I just happened to be working on a .Net project during the writing of this.). If you happen to be using another language, IDE or automation framework such as Selenium IDE or Watir, the concepts are general enough to apply to any development environment with slight modifications for syntax. I have a firm belief (call it a dream if you will) that an automation framework should not be judged by the color of its IDE but the content of its characters.

Further readings/downloads

Product	URL
WatiN	http://sourceforge.net/projects/watin/files/
WatiN - Getting Started	http://watin.sourceforge.net/gettingstarted.html
Watir	http://rubyforge.org/projects/wtr/
Selenium IDE	http://seleniumhq.org/download
Microsoft VSTS	http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=d95598d7-aa6e-4f24-82e3-81570c5384cb

---

More Software Testing Resources

• Software Testing Magazine
• Testing TV
• Functional Testing Tools Directory

This article was originally published in the Spring 2010 issue of Methods & Tools

Back to the archive list