Simulacros de HttpContext.Current en Test Init Method

Estoy tratando de agregar pruebas unitarias a una aplicación ASP.NET MVC que he construido. En mis pruebas unitarias utilizo el siguiente código:

[TestMethod]
public void IndexAction_Should_Return_View() {
    var controller = new MembershipController();
    controller.SetFakeControllerContext("TestUser");

    ...
}

Con los siguientes ayudantes para burlarse del contexto del controlador:

public static class FakeControllerContext {
    public static HttpContextBase FakeHttpContext(string username) {
        var context = new Mock<HttpContextBase>();

        context.SetupGet(ctx => ctx.Request.IsAuthenticated).Returns(!string.IsNullOrEmpty(username));

        if (!string.IsNullOrEmpty(username))
            context.SetupGet(ctx => ctx.User.Identity).Returns(FakeIdentity.CreateIdentity(username));

        return context.Object;
    }

    public static void SetFakeControllerContext(this Controller controller, string username = null) {
        var httpContext = FakeHttpContext(username);
        var context = new ControllerContext(new RequestContext(httpContext, new RouteData()), controller);
        controller.ControllerContext = context;
    }
}

Esta clase de prueba hereda de una clase base que tiene lo siguiente:

[TestInitialize]
public void Init() {
    ...
}

Dentro de este método, llama a una biblioteca (sobre la que no tengo control) que intenta ejecutar el siguiente código:

HttpContext.Current.User.Identity.IsAuthenticated

Ahora probablemente puedas ver el problema. He configurado el HttpContext falso contra el controlador, pero no en este método básico de Init. La prueba / burla de la unidad es muy nueva para mí, así que quiero asegurarme de hacerlo bien. ¿Cuál es la forma correcta para mí de simular el HttpContext para que se comparta entre mi controlador y cualquier biblioteca que se llame en mi método Init?

HttpContext.Currentdevuelve una instancia de System.Web.HttpContext, que no se extiende System.Web.HttpContextBase. HttpContextBasefue agregado más tarde para abordar HttpContextser difícil de burlar. Las dos clases son básicamente no relacionadas (HttpContextWrapper se usa como un adaptador entre ellas).

Afortunadamente, HttpContextes falso lo suficiente como para reemplazar el IPrincipal(Usuario) yIIdentity .

El siguiente código se ejecuta como se esperaba, incluso en una aplicación de consola:

HttpContext.Current = new HttpContext(
    new HttpRequest("", "http://tempuri.org", ""),
    new HttpResponse(new StringWriter())
    );

// User is logged in
HttpContext.Current.User = new GenericPrincipal(
    new GenericIdentity("username"),
    new string[0]
    );

// User is logged out
HttpContext.Current.User = new GenericPrincipal(
    new GenericIdentity(String.Empty),
    new string[0]
    );

Debajo de Test Init también hará el trabajo.

[TestInitialize]
public void TestInit()
{
  HttpContext.Current = new HttpContext(new HttpRequest(null, "http://tempuri.org", null), new HttpResponse(null));
  YourControllerToBeTestedController = GetYourToBeTestedController();
}

Sé que este es un tema más antiguo, sin embargo, burlarnos de una aplicación MVC para pruebas unitarias es algo que hacemos de manera muy regular.

Solo quería agregar mis experiencias Burlándose de una aplicación MVC 3 usando Moq 4 después de actualizar a Visual Studio 2013. Ninguna de las pruebas unitarias funcionaba en modo de depuración y el HttpContext mostraba "no se pudo evaluar la expresión" cuando se trataba de mirar las variables .

Resulta que Visual Studio 2013 tiene problemas para evaluar algunos objetos. Para que la depuración de aplicaciones web simuladas volviera a funcionar, tuve que marcar el "Usar el modo de compatibilidad administrada" en Herramientas => Opciones => Depuración => Configuración general.

Generalmente hago algo como esto:

public static class FakeHttpContext
{
    public static void SetFakeContext(this Controller controller)
    {

        var httpContext = MakeFakeContext();
        ControllerContext context =
        new ControllerContext(
        new RequestContext(httpContext,
        new RouteData()), controller);
        controller.ControllerContext = context;
    }


    private static HttpContextBase MakeFakeContext()
    {
        var context = new Mock<HttpContextBase>();
        var request = new Mock<HttpRequestBase>();
        var response = new Mock<HttpResponseBase>();
        var session = new Mock<HttpSessionStateBase>();
        var server = new Mock<HttpServerUtilityBase>();
        var user = new Mock<IPrincipal>();
        var identity = new Mock<IIdentity>();

        context.Setup(c=> c.Request).Returns(request.Object);
        context.Setup(c=> c.Response).Returns(response.Object);
        context.Setup(c=> c.Session).Returns(session.Object);
        context.Setup(c=> c.Server).Returns(server.Object);
        context.Setup(c=> c.User).Returns(user.Object);
        user.Setup(c=> c.Identity).Returns(identity.Object);
        identity.Setup(i => i.IsAuthenticated).Returns(true);
        identity.Setup(i => i.Name).Returns("admin");

        return context.Object;
    }


}

E iniciando el contexto así

FakeHttpContext.SetFakeContext(moController);

Y llamando al Método en el controlador directamente

long lReportStatusID = -1;
var result = moController.CancelReport(lReportStatusID);

Si el tercero de su aplicación redirige internamente, es mejor burlarse de HttpContext de la siguiente manera:

HttpWorkerRequest initWorkerRequest = new SimpleWorkerRequest("","","","",new StringWriter(CultureInfo.InvariantCulture));
System.Web.HttpContext.Current = new HttpContext(initWorkerRequest);
System.Web.HttpContext.Current.Request.Browser = new HttpBrowserCapabilities();
System.Web.HttpContext.Current.Request.Browser.Capabilities = new Dictionary<string, string> { { "requiresPostRedirectionHandling", "false" } };