Richard Lawrence » WatiN Patterns

WatiN Patterns #3: Don’t Over-specify

Richard Lawrence — Fri, 30 Oct 2009 15:20:31 +0000

After a long hiatus, I’m resuming the WatiN Patterns series. Pattern #1 covered why and how your tests should clean up after themselves. Pattern #2 covered how you should name your tests and why they should only assert one thing.

Pattern #3 is about keeping your tests maintainable by specifying just enough in your element selectors.

If you’re using WatiN, you’re probably also using ASP.NET Web Forms, which means your controls get IDs like this: ctl1001_Content_Content_txtUsername. Though you gave your username text box the ID “txtUsername”, ASP.NET prepends the IDs of each of the container controls to your text box’s ID in the HTML that goes to the browser. This is good for preventing name collisions between controls in different user controls on the same page. But it can lead you to write fragile tests. Consider this example:

1
2
3
4
5
6
7
8
9
10
11
12

[Test]
public void ShouldAuthenticateUsersSuccessfully()
{
using (IE ie = new IE())
{
ie.GoTo("http://mytestapp/");
ie.TextField("ctl1001_Content_Content_txtUsername").TypeText("richard");
ie.TextField("ctl1001_Content_Content_txtPassword").TypeText("password");
ie.Button("ctl1001_Content_Content_btnLogin").Click();
Assert.IsTrue(ie.ContainsText("Welcome, Richard!"));
}
}

Suppose someone moves the login widgets outside one of those nested “Content” controls. Now our test fails. Did login stop working? Probably not. But, thanks to ASP.NET’s “helpful” ID scheme, we can no longer find the login widgets—their IDs have changed. We could update the test to the new IDs:

1
2
3
4
5
6
7
8
9
10
11
12

[Test]
public void ShouldAuthenticateUsersSuccessfully()
{
using (IE ie = new IE())
{
ie.GoTo("http://mytestapp/");
ie.TextField("ctl1001_Content_txtUsername").TypeText("richard");
ie.TextField("ctl1001_Content_txtPassword").TypeText("password");
ie.Button("ctl1001_Content_btnLogin").Click();
Assert.IsTrue(ie.ContainsText("Welcome, Richard!"));
}
}

Or we could solve the root problem of fragile tests:

1
2
3
4
5
6
7
8
9
10
11
12

[Test]
public void ShouldAuthenticateUsersSuccessfully()
{
using (IE ie = new IE())
{
ie.GoTo("http://mytestapp/");
ie.TextField(new Regex("txtUsername$")).TypeText("richard");
ie.TextField(new Regex("txtPassword$")).TypeText("password");
ie.Button(new Regex("btnLogin$")).Click();
Assert.IsTrue(ie.ContainsText("Welcome, Richard!"));
}
}

WatiN accommodates regular expressions instead of strings for IDs. Now we’ve specified, “a text field with an ID ending in txtUsername” (note the ending dollar sign), instead of, “a text field with exactly the ID ctl1001_Content_Content_txtUsername.” Much more flexible.

To keep your tests from being fragile, when selecting elements on the page, use the least specific method and value necessary to find the element you want.

WatiN Patterns #2: One Assertion and a Name to Match

Richard Lawrence — Wed, 11 Feb 2009 23:46:19 +0000

One way to keep your WatiN tests maintainable is to keep them small and focused. WatiN Pattern #2, then, is a way to do just that.

Your tests should assert one thing. Just one. And the name of the test should describe whatever it is you’re asserting. Looking at our example from last time, we see that we’ve got the one assertion part right, but the name doesn’t match.

1
2
3
4
5
6
7
8
9
10
11

[TestMethod]
public void SearchPageTest()
{
using (IE ie = new IE())
{
ie.GoTo("http://www.google.com/");
ie.TextField(Find.ByName("q")).TypeText("Richard Lawrence");
ie.Button(Find.ByName("btnG")).Click();
Assert.IsTrue(ie.ContainsText("www.richardlawrence.info"));
}
}

In a nod to the BDD approach (more BDD to show up in future patterns), I like to name the test class for the thing we’re testing and use test names starting with “Should” that specify what the thing we’re testing ought to do. So, we could change our example to something like this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

// using statements, namespace declaration, etc.
// ...
[TestClass]
public class GoogleSearchPage
{

// ...

[TestMethod]
public void ShouldReturnSearchResultsSuccessfully()
{
using (IE ie = new IE())
{
ie.GoTo("http://www.google.com/");
ie.TextField(Find.ByName("q")).TypeText("Richard Lawrence");
ie.Button(Find.ByName("btnG")).Click();
Assert.IsTrue(ie.ContainsText("www.richardlawrence.info"));
}
}
}

Now we have one assertion, and our test name indicates that it’s asserting that the Google search page should return search results successfully. If that test fails, we know what’s gone wrong.

It’s not yet transparent that the assertion on line 17 does what the test name indicates, but we’ll deal with that in future patterns.

WatiN Patterns #1: No Browser Left Behind

Richard Lawrence — Wed, 04 Feb 2009 23:35:44 +0000

In my previous posts on WatiN, I lamented the shortage of online documentation and resolved to do something about it by documenting the patterns I’ve found for good WatiN tests. This is the first in a series in which I’ll take an example of the typical beginner WatiN test I see and refactor it to use the patterns I recommend.

Consider this test:

1
2
3
4
5
6
7
8
9
10

[TestMethod]
public void SearchPageTest()
{
IE ie = new IE();
ie.GoTo("http://www.google.com/");
ie.TextField(Find.ByName("q")).TypeText("Richard Lawrence");
ie.Button(Find.ByName("btnG")).Click();
Assert.IsTrue(ie.ContainsText("www.richardlawrence.info"));
ie.Close();
}

It has a few problems, but I want to highlight one in this post: This test doesn’t properly clean up after itself. If the code on lines 66-70 throws an exception or if the assertion fails, line 71 will never be executed. When you’re testing on your own machine, this can be annoying—you have to close the IE window manually. But if the test runs unattended (e.g. as part of continuous integration) it can be much more than annoying.

I’ve sometimes seen this attempt to work around the problem:

1
2
3
4
5
6
7
8
9
10
11

[TestMethod]
public void SearchPageTest()
{
IE ie = new IE();
ie.GoTo("http://www.google.com/");
ie.TextField(Find.ByName("q")).TypeText("Richard Lawrence");
ie.Button(Find.ByName("btnG")).Click();
bool resultsFound = ie.ContainsText("www.richardlawrence.info");
ie.Close();
Assert.IsTrue(resultsFound);
}

Introducing a local boolean to indicate success and closing the browser before the assertion ensures that the browser gets closed whether the assertion fails or succeeds. However, it won’t necessarily close the browser in case of an exception.

Fortunately, WatiN.Core.IE implements IDisposable, so you can do this:

1
2
3
4
5
6
7
8
9
10
11

In case you’re not familar with the “using” statement, it’s a shortcut for this:

1
2
3
4
5
6
7
8
9
10
11
12
13

IE ie;
try
{
ie = new IE();
// whatever you're going to do with ie
}
finally
{
if (ie != null)
{
ie.Dispose();
}
}

At the end of the using block (or when an exception is thrown) ie.Dispose() is called, which closes the browser window.

Use this pattern in your WatiN tests to ensure that your tests clean up after themselves and leave no browser window behind.