Mock HttpContext.Current w metodzie inicjowania testu

Próbuję dodać testy jednostkowe do aplikacji ASP.NET MVC, którą zbudowałem. W moich testach jednostkowych używam następującego kodu:

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

    ...
}

Z następującymi pomocnikami do mockowania kontekstu kontrolera:

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;
    }
}

Ta klasa testowa dziedziczy z klasy bazowej, która ma następujące elementy:

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

Wewnątrz tej metody wywołuje bibliotekę (nad którą nie mam kontroli), która próbuje uruchomić następujący kod:

HttpContext.Current.User.Identity.IsAuthenticated

Teraz prawdopodobnie widzisz problem. Ustawiłem fałszywy HttpContext względem kontrolera, ale nie w tej podstawowej metodzie Init. Testowanie jednostkowe / mockowanie jest dla mnie nowością, więc chcę się upewnić, że robię to dobrze. Jaki jest prawidłowy sposób, w jaki mogę wyszydzać HttpContext, aby był współdzielony przez mój kontroler i wszystkie biblioteki, które są wywoływane w mojej metodzie Init.

HttpContext.Currentzwraca instancję System.Web.HttpContext, która się nie rozszerza System.Web.HttpContextBase. HttpContextBasezostał dodany później, aby rozwiązać HttpContextproblem trudny do wyszydzenia. Te dwie klasy są w zasadzie niepowiązane ( HttpContextWrappersą używane jako adapter między nimi).

Na szczęście HttpContextsam w sobie jest wystarczająco fałszywy, aby zastąpić IPrincipal(User) i IIdentity.

Poniższy kod działa zgodnie z oczekiwaniami, nawet w aplikacji konsoli:

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]
    );

Poniżej Test Init również wykona zadanie.

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

Wiem, że to starszy temat, ale mockowanie aplikacji MVC do testów jednostkowych jest czymś, co robimy bardzo regularnie.

Chciałem tylko dodać swoje doświadczenia Mockowanie aplikacji MVC 3 przy użyciu Moq 4 po uaktualnieniu do Visual Studio 2013. Żaden z testów jednostkowych nie działał w trybie debugowania, a HttpContext pokazywał „nie można ocenić wyrażenia” podczas próby zerknięcia na zmienne .

Okazuje się, że w programie Visual Studio 2013 występują problemy z oceną niektórych obiektów. Aby ponownie uruchomić debugowanie fałszywych aplikacji internetowych, musiałem zaznaczyć opcję „Użyj zarządzanego trybu zgodności” w menu Narzędzia => Opcje => Debugowanie => Ustawienia ogólne.

Generalnie robię coś takiego:

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;
    }


}

I inicjując taki kontekst

FakeHttpContext.SetFakeContext(moController);

I wywołanie metody w kontrolerze prosto do przodu

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

Jeśli strona trzecia Twojej aplikacji przekierowuje wewnętrznie, lepiej jest mockować HttpContext w poniższy sposób:

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" } };