Microsoft's 99% Rule - or - sealed strikes again.

Microsoft has a madding habit of getting things 99% right, with the last 1% making it impossible to do what I want to do. It drives me absolutely bonkers some times.

Case in point. I'm working on a set of ASP.Net server controls. Being a good little XP programmer, I want to write unit tests for the controls. I'd rather not require a real web application to host the controls in order to test, so I figured I'd create my own subclass of Page that can simulate the lifecycle of a server control. Seemed like a reasonable idea to me. After all, session data, viewstate, form data - they're all just name/value pairs, right? Not too hard to save and restore as needed. I figured I wouldn't be able to test every bit of control functionality this way, but I should be able to test a lot.

It didn't take very long before I hit an impasse. About 5 minutes, actually. One of the controls has the option to use session state for data storage. When a new Page object is created, its Session member is null, and there's no setter for it. Aha, I think. the getter is virtual, I'll override it and return my own HttpSessionState object. Wrong. The HttpSessionState class is sealed and has no public constructor. Heck, HttpSessionState doesn't even implement IDictionary, so I can't treat it generically. So I'm stuck.

The Sealed Sucks thread on Chris Sells' Spout has a rousing discussion on the topic of sealed classes in the FCL. Obviously Web Forms is just as prone to this as Windows Forms.

Oh, and by the way, isn't ASP.Net session state a perfect example of where interface-based programming makes sense? Hmm...state information that's presented in a consistent way but with multiple options for backend storage - in-process, state server, and sql server. Why on earth would they elect to make a monolithic class that supports all three options? Can you say "pluggable session state back-end"? I guess Microsoft can't. So much for the idea of session state stored in an Oracle server.

Anybody out there writing unit tests for server controls? Care to share your strategies?

 

3 Comments

  • Your right on the money...



    That was what I was looking at doing was creating a session state stored in Oracle when I ran into the same problem.



    It is not inheritable... and does not implement an interface that I could.



    ARG!!



  • Apperantly (I've just started working with it) - you should use an already exists variable called "Session" - It is a HttpSessionState object.

  • Ever thought of using the HttpSessionStateWrapper class? It is provided specifically for unit testing according to the MSDN description.

Comments have been disabled for this content.