I’m all for unit testing and even Test Driven Development (although I can do without some of the TDD zealotry out there).  Recently, I began writing some libraries for ASP.NET applications and really struggled with how I was going to write my unit tests to test my work.  Certainly, we have the MVP and MVC patterns and lots of great examples, frameworks, and miscellaneous tools to help you implement these patterns and greatly simplify the unit tests you need to write—but I’m writing an ASP.NET-based library, not an end-to-end application.

Here’s what I’m doing:

I have to write components around a commercial security device that injects certain identity information into the request header of http requests (via an ISAPI filter).  Specifically, I am writing an HttpModule (a few, actually, for different scenarios) to build out a custom Identity object and insert it into the Current.User object.  Additionally, I’m writing a couple of RoleProviders to manage the roles returned by the device.

These components obviously have a tight reliance on HttpContext, so how do you unit test under such a scenario?  Incidentally, these components have to work with a pure ASP.NET 2.0 solution, which means I don’t have access to the new System.Web.Abstractions assembly which is supposed to make testing in this space much easier—I’d still like to see what the Abstractions assembly could do for me, though.

Phil Haack offered up this effort at mocking HttpContext, but I simply couldn’t get that to work for my scenario.  I then looked at TypeMock.  Here’s some code I wrote against TypeMock that still doesn’t work:

[Test]
[VerifyMocks]
public void TestOnAuthenticateRequest2()
{
string fname = "John";
string lname = "Smith";
string fullName = fname + " " + lname;
string roles = "cn=Role1,ou=APPS,o=SomeCompany:cn=Role2,ou=APPS,o=SomeCompany";
string login = "jxsmith";
string commonName = "Smith";
//TestedImplementation is an alias for my custom HttpModule
TestedImplementation target = new TestedImplementation();
MockObject<HttpApplication> applicationMock = MockManager.MockObject<HttpApplication>();
MockedEvent authRequestEvent = applicationMock.ExpectAddEvent("AuthenticateRequest");
target.Init(applicationMock.Object);
MockObject<HttpRequest> httpRequestMock = MockManager.MockObject<HttpRequest>();
applicationMock.ExpectGetAlways("Request", httpRequestMock.Object);
MockObject<HttpResponse> httpResponseMock = MockManager.MockObject<HttpResponse>();
applicationMock.ExpectGetAlways("Response", httpResponseMock.Object);
httpRequestMock.ExpectGetAlways("HttpMethod", "POST");
httpRequestMock.ExpectGetAlways("AppRelativeCurrentExecutionFilePath", "foobar.aspx");
httpRequestMock.Object.Headers.Add("LOGIN", login);
httpRequestMock.Object.Headers.Add("FIRSTNAME", fname);
httpRequestMock.Object.Headers.Add("LASTNAME", lname);
httpRequestMock.Object.Headers.Add("ROLE", roles);
httpRequestMock.Object.Headers.Add("COMMONNAME", commonName);
authRequestEvent.Fire(applicationMock.Object, EventArgs.Empty);
//once I can actually mock the context, I'll write some asserts
}

As I recall, I could never figure out how to stub in data to the request header of the mocked request.  Doing this is pretty important as my components behave differently based on the data present (or not present) in the header.  A sister project to TypeMock called Ivonna (no pun intended) actually might let me do this, though.  Of course, both these products cost money—so, I’d still like to find a free answer to my problem.

Some folks have suggested refactoring my IHttpModule and RoleProvider implementations such that I move as much code as possible out of the direct implementations and into separate classes that can be more easily tested.  I assume they mean separate private classes that aren’t exposed to clients using my components.  To that end, here’s what I tried in my implementation:

public class MyHttpModule : IHttpModule
{
public void Init(HttpApplication context)
{
context.AuthenticateRequest += OnAuthenticateRequest;
}
private void OnAuthenticateRequest(object sender, EventArgs e)
{
HttpApplication httpApp = sender as HttpApplication;
MyHttpModuleHelper helper = new MyHttpModuleHelper();
helper.DoStuff(httpApp.Request.Headers);
}
public void Dispose()
{
//dispose stuff here
}
}
//the private class that can be tested
class MyHttpModuleHelper
{
public string[] DoStuff(NameValueCollection headers)
{
//process the headers in some way
return new[]{"hello world"};
}
}

And in my unit test class:

private MethodInfo DoStuffMethod;
private object MyHttpModuleHelper;
[SetUp]
public void Init()
{
Assembly testAssembly = Assembly.GetAssembly(typeof (MyHttpModule));
MyHttpModuleHelper =
testAssembly.CreateInstance("MyNamespace.HttpModules.MyHttpModuleHelper");
Type helperType = MyHttpModuleHelper.GetType();
BindingFlags bf = BindingFlags.Instance | BindingFlags.Public;
DoStuffMethod = helperType.GetMethod("DoStuff", bf);
}
[Test]
public void DoStuffTest()
{
NameValueCollection stubHeaders = new NameValueCollection();
//stubHeaders.Add();  //add some fake data
object returnValue = DoStuffMethod.Invoke(MyHttpModuleHelper, new object[] { stubHeaders });
Assert.IsTrue(returnValue.GetType().IsArray, "Expected the type to be a string array");
string[] roleArray = returnValue as string[];
Assert.IsTrue(roleArray.Length == 1, "Expected the array length to be 1");
StringAssert.IsMatch(roleArray[0], "hello world", "Expected the first value to be hello world");
}

This works, but it’s such a pain.  One frustration I’ve had is that I tend to refactor my helper methods a lot—the parameters I pass, the return values I return, even the names of the methods themselves.  Every time I refactor, I have to go back to my unit tests and refactor them accordingly—even Resharper isn’t smart enough to cascade through such refactoring when I’m using Reflection to invoke those methods.  Do I have any other options?

Virtually at the end of my rope, I even contemplated the mildly insane notion of writing a test ASP.NET app to Response.Write out values from my Identity and Principal objects rendered by my HttpModules and RoleProviders…then use a product like Selenium or WatiN to perform assertions on those values in the pages.

Just when I thought all hope was lost, a friend of mine reminded me of the ASP.NET host adapter.  The ASP.NET host adapter allows you to run a unit test that smells a lot more like an integration test—like integration testing, you have to develop a web app within which your test will run.  The big difference, though, is that you can perform assertions on server-side objects. 

You invoke the ASP.NET host adapter by decorating your MSTTest test method with the attribute, [HostType(“ASP.NET”)].  You also have to include the attribute [UrlToTest(“someUrl”)]—where you specify the ASPX page that establishes the server-side context you’d like to test.  You can add one more attribute, AspNetDevelopmentServerHost, to have you test web app run under the Development Server (a.k.a. Cassini) as opposed to IIS.

It’s lame that I need a web app to run a unit test, but I’m desperate, so I’ll play along.  As I started all this work, one obstacle I kept running into was the UrlToTest attribute: it seemed to only understand the “localhost” domain name.  As I mentioned earlier, I’m writing components that have to play nicely under this third party ISAPI filter.  The ISAPI filter will only be invoked when it detects certain domain names it’s configured to listen for.  Localhost is not one of these—if it were, every time anyone would run an app under localhost, the ISAPI filter would invoke a particular set of policies that may or may not have anything to do with your work—frankly, it would just be bad.

Instead, in Development, until we can get a real IP assigned to our app, we create fictitious domain names by mapping 127.0.0.1 to that fictitious name in our local hosts file.  We configure the ISAPI filter to apply our particular policy when it detects this fictitious host name being requested and all is right in the world.  That is, until you try to invoke the ASP.NET host adapter using your fictitious domain name: it seems that the ASP.NET host adapter could care less about what mappings I have in my hosts file.  I even tried my own IP address and it didn’t like that, either.  Finally, I tried my machine name and, ta-da, the ASP.NET host adapter worked and my test ran.  It just so happens that I can use my machine name as one of these fictitious domain names, but I consider that bad form—it tightly associates my machine to the development environment.  Now, even my tests are tightly associated to my machine.  That really stinks—so much for running my tests on a separate build server…they just won’t work.

Here’s an example of one of my test methods:

[TestMethod]
[HostType("ASP.NET")]
[UrlToTest("http://MyMachineName/SomeVirDir/Default.aspx")]
public void IdentityType()
{
Assert.IsNotNull(HttpContext.Current.User, "Current.User object is null");
Assert.IsNotNull(HttpContext.Current.User.Identity, "Current.User.Identity object is null");
Assert.IsInstanceOfType(HttpContext.Current.User.Identity, typeof(MyCustomIdentity),
"Current identity is not of type MyCustomIdentity");
}

Another thing I noted regarding the UrlToTest attribute is that it only likes my “short” machine name—I had to truncate off my DNS suffix in order to get my test to run properly.

So, this is a terrible way to test—my tests are tightly bound to my machine and require a web app of all things to run a simple unit test—but, at least it works on my machine.  The alternatives would be scraping together a few hundred bucks to buy TypeMock/Ivonna (which would come out of my pocket, not my company’s—see here on why that’s the case) or upgrade to .NET 3.5 SP1 with hopes that the new Abstractions assembly can help me out.

For the moment, I’ll stick with this approach.  My next challenge is to figure out how to dynamically change my web configuration between tests to swap out HttpModules and RoleProviders, as I need to test a few of these.  Any ideas?