Using ASP.NET development server for testing with WatiN

For many ASP.NET and Sharepoint developers WatiN (http://watin.sourceforge.net/ ) has become a frequently used tool to create functional tests and eliminate manual testing as much as possible. In my environment I use WatiN from within NUnit tests. To integrate all of these components in my Visual Studio setup, I also use http://www.testdriven.net/, a plug-in that supports most of the commonly used testing frameworks and among other things makes it possible to right-click within the code of the test and execute it with or without debugging.

This is all great, but how do I make sure that (1) the tests run independently and there are no leftovers from previous test sessions and (2) that the tests ca run with minimum configuration, preferably no configuration at all - simply build and run.

The ASP.NET development server (Cassini) comes to the rescue. This great application is always available and there is no configuration required to run any ASP.NET site at all. If only I can start Cassini in the beginning of each test run and then in my test open a new browser session for each individual test and close it after the test is completed!

Jesus Jimenez has a great article on Code Project (http://www.codeproject.com/KB/aspnet/WatiN.aspx), but the way he structured the SetUp() starts and stops the dev server for each test. Since I prefer to have more small tests rather than only couple of big, stopping and starting the ASP server seems unnecessary and not efficient.

The key here is that in the test run setup [SetUp] I prefer to detect if Cassini runs on the predefined port used for testing. If it is, we just keep going. If it is not we start a new instance of the development web server.

Other than that the test structure remains the same. For each test we open a new IE session and close it in the test tear down. Here is some code:

[TestFixture]
public class TestTemplate
{
private const string devServerPort = "12345";
private const string homePage = "default.aspx";
private IE ie;
private string rootUrl;
private string homePageUrl;

[SetUp]
public void SetUp()
{

bool IsWebStarted;
rootUrl = string.Format("http://localhost:{0}", devServerPort);
homePageUrl = string.Format("{0}/{1}", rootUrl, homePage);
try
{
// Check if Dev WebServer runs
ie = new IE(rootUrl);
IsWebStarted = ie.ContainsText("Directory Listing -- /");
}
catch
{
IsWebStarted = false;
}

if (!IsWebStarted)
{
// If not start it
string command = Path.Combine(
RuntimeEnvironment.GetRuntimeDirectory(),
"WebDev.WebServer.EXE");

string rootPath = Environment.CurrentDirectory.Substring(0, Environment.CurrentDirectory.LastIndexOf('\'));
string commandArgs = string.Format(" /path:"{0}" /port:{1} /vapth:/", rootPath, devServerPort);

Process cmdProcess = new Process();
cmdProcess.StartInfo.Arguments = commandArgs.ToString();
cmdProcess.StartInfo.CreateNoWindow = true;
cmdProcess.StartInfo.FileName = command;
cmdProcess.StartInfo.UseShellExecute = false;
cmdProcess.StartInfo.WorkingDirectory = command.Substring(0, command.LastIndexOf('\'));
cmdProcess.Start();

// .. and try one more time to see if the server is up
ie.GoTo(rootUrl);
}
Assert.IsTrue(ie.ContainsText("Directory Listing -- /"));

// Give some time to crank up
System.Threading.Thread.Sleep(1000);

}

[TearDown]
public void TearDown()
{
ie.Close();
}

[Test]
public void TestInstantiate()
{
ie.GoTo(homePageUrl);
// insert test logic here

}

This shaves some time from the testing process, which for longer test sequences might be a significant gain.

Dovizhdane!

Comments

Unknown said…
Thanks Mikhail, I just added the same new feature to our web testing tool InCisif.net. See my post at
InCisif.net And Cassini

Frederic Torres
www.InCisif.net
Web Testing with C# or VB.NET