codeflood logo

Automated Testing and Sitecore - Part 7

In the previous part of this series we covered testing the static output and behaviors of Sitecore presentation components such as rendering, layout and sublayout. But what about testing the dynamic behaviors of a component, such as "what happens when I push the button?", or "did my javascript make the ajax call to grab the content from the CMS?". In this part of the series I'll take you through how I use WatiN to test the dynamic aspects of my Sitecore presentation components.

WatiN is a browser driver that instantiates a new browsing window and provides access directly to the DOM to allow manipulation and testing. WatiN only currently supports IE. If you need cross browser testing you will have to use one of the other browser drivers such as Selenium.

Because WatiN needs to interact with applications on your desktop (IE) I would not suggest running your WatiN tests in the custom test runner. In fact, I haven't yet been able to get WatiN to run in the custom test runner due to the threading apartment of the ASP.NET requests.

The first thing we need to do is to create some test content programmatically using the techniques which have been covered in previous parts of the series. The gist of this technique is to have a layout which does item creation and cleanup and we call an item with this layout across HTTP, so our windows app can control the lifetime of the test items.

Now that we have some content to test against we can create a WatiN.IE object to make the request and verify the results.

const string DOMAIN = "http://localhost";
using (WatiN.Core.IE ie = new WatiN.Core.IE(DOMAIN + "/page1.aspx"))
  Assert.AreEqual(ie.Paras[0], "expected text");

We can find elements in the DOM in a few ways using WatiN. Firstly as shown above, you can access a kind of element, such as a paragraph above, by index. Generally this isn't adequate and you'll want to be finding by ID. So in that case we can use the method on the IE object rather than the property.


Keep in mind the ID we're searching for will be the clientID in ASP.NET controls which may be of the format "ctlxx_name". Make sure you get the right ID.

We can also make use of LINQ for querying elements by other parameters. In the below code snippet I'll locate the first div with a class attribute of "breadcrumb".

var match = from WatiN.Core.Div d in ie.Divs where
  d.ClassName == "breadcrumb" select d;
WatiN.Core.Div div = match.ElementAt(0);

I can also use a WatiN constraint to find an element by an attribute.


So now that we know how to find elements in the DOM, we can start testing the dynamic behaviors of our presentation components. First we'll find a textbox, put a value in it, then click the submit button of the form and validate the text in the span.

const string DOMAIN = "http://snd.localhost";
using (WatiN.Core.IE ie = new WatiN.Core.IE(DOMAIN + "/wt.aspx"))
  WatiN.Core.TextField tf = ie.TextField("username");
  tf.Value = "Al";
  WatiN.Core.Button b = ie.Button("btnSubmit");
  WatiN.Core.Span s = ie.Span("lblMsg");
  Assert.AreEqual("Please provide your password", s.InnerHtml);

Note the WaitForComplete call in there which blocks our test thread while IE does what it needs to. The span above may get populated either through javascript or a postback. It really doesn't matter. But this also shows that we can use the exact same techniques to test both javascript logic and server side logic.

Footnote for Vista users: make sure the site you're testing is in your trusted sites list so WatiN can interact with the IE window properly. Check out for details.



WatiN 2.0 *does* support FF, although it is currently beta.

Alistair Deneys

Thanks for that Daaron, I hadn't heard that. Will be great to see how that stacks up against Selenium for Firefox support. Looking forward to it.

Thanks for the blog about WatiN! About calling WaitForComplete. It shouldn't be necessary to call this explicitly cause WatiN also calls the method internally when it Clicks on a button are changes the value (basically when it changes anything on an html element or navigates to a page). Will slim done the code some.
Regards, Jeroen Lead dev WatiN

Alistair Deneys

Thanks Jeroen. I guess I was being overly careful. Although as you point out, calling WaitForComplete after interacting with the DOM isn't required I thought I read somewhere that you did need to call that after requesting a new URL with the GoTo method. Perhaps that was in an older version.

Leave a comment

All fields are required.