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 »

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 »