Writing WatiN Tests
time to read 3 min | 505 words

The most important thing to understand about WatiN tests is that the moment you put in Ajax, you are inheritedly testing multi threaded code. This means that you are going to be aware about concurrency issues.

Here are a few recommendations:

  • Only open IE once per test fixture - this has a significant overhead, so we want to reduce it as much as possible.
  • Make sure that in the setup you go back to the page and refresh. This is important to handle browser cache issues.
  • Build a set of expectations to handle waiting, it will make your life much easier.

Here is an example of a test:

[Setup]
public void Setup()
{
 Open("policies/newPolicy.aspx");
 ie.Refresh();//avoid cached data, and start from clean slate
}


[Test]
public void CanAddNewNote()
{
 ie.Button(PartialId("AddNewNote")).Click(); 
 ie.SelectList(PartialId("Customers")).Option("Rhino").Select();//cascading drop down
 WaitUntilEnabled("Policies");//wait for child drop down to become enabled
 
 ie.SelectList(PartialId("Policies")).Option("Home").Select();
 ie.TextField(PartialId("NoteText")).TypeText("Should we do that?");
 ie.Button(PartialId("SaveNote")).Click();// ajax call.
 
 WaitUntilHidden("NewNoteDiv");//finished updating the page
 AssertTextPresent("Should we do that?");
}

PartialId() will look for a control that ends with the text that you gave it, this is done to handle ASP.Net control name mangling.

Tweet Share Share 6 comments