The Lightweight Test Automation Framework is a browser automation framework like WatiN and Selenium RC that allows you to create automated integration tests.  Its a beta release from MS and can be found on Codeplex at:

http://aspnet.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=22739

I first read about it from Steve Sanderson's blog where he describes how to use it with an ASP.NET MVC project.

I am supporting a legacy web forms application and have a typical web application setup so I'll explain what I did to get up and running in a matter of minutes with LTAF.

  1. Download LTAF; you can use the "... for ASP.NET Samples" link and pull the *.dll out of the Bin folder and the contents of the Test folder, or you could build from source using the "... for ASP.NET Source"
  2. Create a new Class Library project in your solution and name it appropriately - Company.Tests.Integration.Site - for example
    1. For this project's properties alter the output assembly's name to begin with App_Code - this will slightly speed up web test load times and can help solve problems you may experience if your web application references tons of assemblies, i.e. App_CodeCompany.Tests.Integration.Site
  3. Add a reference to Microsoft.Web.Testing.Light.dll to your Company.Tests.Integration.Site project
  4. Copy and add to your web project (Company.Site) the Test folder; you can name the folder anything you want and you don't strictly have to add it to your project but I did for convenience for Start > Debug
    1. Remember to alter your build process to remove the Test folder for production releases
  5. Alter the web.config file for your Company.Site to allow anonymous access to the Test folder:
  6. <location path="Test">  
      <system.web>
        <authorization>
          <allow users="*" />
        </authorization>
      </system.web>
    </location>
    1. Again, remember to alter your build process to eliminate this node from your production web.config
  7. Add a reference to your integration test project, Company.Tests.Integration.Site, to your web application, Company.Site
  8. Let's test the login page (here I assume that "Login.aspx" is the name of your login page and its in the root of the application and you've used an <asp:Login /> control)...
    1. Create a new class LoginTests in your Company.Tests.Integration.Site project and eliminate the file's contents - it is very important that all tests exist outside of a namespace
    2. Paste this code into the body of your LoginTests.cs file:
    3. using Microsoft.Web.Testing.Light;
      
      [WebTestClass]
      public class LoginTests  
      {  
          [WebTestMethod]
          public void SignInAndSignOut()
          {
              var page = new HtmlPage("Login.aspx");
      
              page.Elements.Find("UserName").SetText("someuser");
              page.Elements.Find("Password").SetText("yourPW");
              page.Elements.Find("LoginButton").Click(WaitFor.Postback);
      
              // you'll need to determine what a good landmark for your
              // application is upon successful login
              var logoutLink = page.Elements.Find("LogoutHyperlink");
              Assert.AreEqual("[Logout]", logoutLink.GetInnerText());
      
              logoutLink.Click(WaitFor.Postback);
      
              Assert.IsNotNull(page.Elements.Find("LoginButton"));
          }
      }
  9. Set your Company.Site as the startup project if its not already, and Tests/Default.aspx as the startup page; run from Visual Studio

Magic!  This is my first use of a browser automation framework for integration testing and while it has its pitfalls, it does work and looks very promising.

Notes
  • Looks like all your integration tests must exist in the same assembly
    • Source code for LTAF is available so making this a configuration option is a possibility
  • All tests must exist outside of namespaces
  • Prefixing your integration tests assembly with App_Code can help work around assembly loading problems as the test runner searches for WebTestClass attributes
  • Remember to have your production build process eliminate the Tests folder and associated integration test assembly