Now that I’m finally back in ASP.NET user land, I can finally scratch an itch of mine to use WatiN on a real project.  I’m thoroughly impressed with the product, even though the documentation is fairly light; the thing is the API is so straight forward you don’t need a bunch of documentation which allows you to ramp up and use it very quickly.  How nice is that?

The one problem I had was that Session state and general page state was being shared between each of my tests initially which would cause some tests to break because they expected the page to be in one state, but another test had changed the state to something else.  I had originally scoped my IE instance at the fixture level, which caused some tests to break because of the order they were being run by NUnit.  I ended up having to change my IE scope from fixture level, to test level which was quite a bit slower.  Here’s one of my tests:

[Test]
public void SearchResultsAreDisplayedOnSearchClick()
{
   using (IE ie = CreateIE())
   {
      ie.Link(Find.ById(new Regex(@"m_btnSearch\b"))).Click();
      string borrowerName = GetResultTable(ie).TableRows[1].TableCells[1].Text;

      Assert.AreEqual("George Washington", borrowerName,
          "Search results did not display as expected.");
   }
}

private Table GetResultTable(IE ie)
{
   return ie.Table(Find.ById(new Regex(@"m_resultsGrid\b")));
}

private IE CreateIE()
{
   IE ie = new IE(SearchUrl);
   ie.Refresh();
   return ie;
}

What I need to do is to make my tests less granular, less like a unit test and more like a functional integration test.  I would rather not do that, but I think for more complicated testing scenarios I will have to do this anyway.  I should stop trying to fight what should be natural here.  Basically I need to combine what are now several tests into a single test.  An end user would likely perform several actions on the page before moving on to anther page, and so should my WatiN tests.  After all, these aren’t unit tests – those of course are already all green.