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"))
{
  ie.WaitForComplete();
  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.

ie.TextField("txtUsername");

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.

ie.TextField(WatiN.Core.Find.ByClass("username"));

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"))
{
  ie.WaitForComplete();
  WatiN.Core.TextField tf = ie.TextField("username");
  tf.Value = "Al";
  WatiN.Core.Button b = ie.Button("btnSubmit");
  b.Click();
  ie.WaitForComplete();
  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 http://codebetter.com/blogs/james.kovacs/archive/2008/06/18/running-watin-tests-on-vista.aspx for details.