I just went through this yesterday with a MonoRail application that I
needed to add some unit testing to.
The "Home" controller had login and logout methods for logging into
the system. I used ASP.NET Forms Authentication so my login method
had stuff like creating the FormsAuthenticationTicket, creating a
cookie, adding it to the Response.Cookies collection, etc... My
Logout method called FormsAuthentication.SignOut(), Session.Abandon(),
cookie expiration. Also, the HttpApplication had code in the
AuthenticateRequest to determine if the user was already logged on --
again, by digging into cookie values and looking for stuff specific to
FormsAuthentication.
I had to abstract this authentication process into something I could
mock. So I created a simple authentication interface:
public interface IAuthenticationService
{
/// <summary>
/// Signs a user into the system.
/// </summary>
/// <param name="user"></param>
void SignIn(User user);
/// <summary>
/// Signs a user out of the system.
/// </summary>
void SignOut();
/// <summary>
/// Finds the currently logged in user (if any)
/// </summary>
/// <returns>The current user or <c>null</c> if no user was
found.</returns>
User FindLoggedInUser();
}
NOTE: The "User" class above is a class in my application that
represents a user.
My Home controller constructor was changed to accept an instance of
IAuthenticationService (which is resolved at run-time by Windsor).
For unit testing, I can create a mock or sub for
IAuthenticationService. For run-time, I created a
FormsAuthenticationService and implemented IAuthenticationService.
This is where all of the old code got moved to (the stuff that dealt
directly with FormsAuthenticationTicket, FormsAuthentication.SignOut,
Session.Abandon, etc...
It worked out really well and I was really happy to get that
FormsAuthentication stuff out of my controller (plus, my login/logout
process now has some automated unit tests!).
--
Patrick Steele
http://weblogs.asp.net/psteele
On Fri, Aug 28, 2009 at 2:00 AM, TheMightyKumquat<[email protected]> wrote:
>
> I'm running a lot of unit tests on a class inheriting from another
> class, where the base class' methods make a lot of calls involving
> HttpContext.Current.Session. When unit tests run, of course, they
> fail, because there is no HttpContext when the test is executed by the
> Visual Studio IDE.
>
> I've done a bit of Googling for a workaround and found a couple of
> things - something called HttpSimulator and also a Scott Hanselman
> blog page that discussed trying to simulate Session using Rhino Mocks,
> but I don't really understand the usage of either. Does anyone have
> experience trying to deal with Session in unit tests, and is there a
> "best practice" solution involving Rhino Mocks? I'd love to hear
> everyone's input.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Rhino.Mocks" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/rhinomocks?hl=en
-~----------~----~----~----~------~----~------~--~---
