Richard Lawrence

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.

Read the rest of this entry »

Good user stories follow Bill Wake’s INVEST model. They’re Independent, Negotiable, Valuable, Estimable, Small, and Testable. The small requirement drives us to split large stories. But the stories after splitting still have to follow the model.

Many new agile teams attempt to split stories by architectural layer: one story for the UI, another for the database, etc. This may satisfy small, but it fails at independent and valuable.

Over my years with agile, I’ve discovered nine patterns for splitting user stories into good, smaller stories. Read on »

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.

Read the rest of this entry »

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:

63
64
65
66
67
68
69
70
71
72

        [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.

Read the rest of this entry »

At my current client, we’ve decided to use WatiN, largely for the C# vs. Ruby reason I discussed earlier this week. After spending a week working with WatiN (following a year of rarely using it), I’m impressed. Ruby and the active Watir community still have their advantages. But WatiN has really come into its own with C# 3.0 features like lambdas. I’m pleased with the test code we’re producing in terms of readability, speed, flexibility, and maintainability. I’ve proposed an Agile 2009 tutorial session on the patterns I’m using to get those results, and I’ll post more on that topic here soon. (Which will hopefully help with one of WatiN’s shortcomings—documentation.)