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.