HttpContext.Current ma wartość zero po oczekiwaniu (tylko w testach jednostkowych)

Question

Piszę test jednostkowy dla aplikacji internetowej MVC 5. Kpiłam z testu HttpContext.Current. Kiedy uruchomić następujące postaci kodu testy httpSessionStateAfter rzut

System.AggregateException: Wystąpił jeden lub więcej błędów.
----> System.NullReferenceException: Odwołanie do obiektu nie jest ustawione na wystąpienie obiektu.

Dzieje się tak tylko po przeprowadzeniu testów jednostkowych. Po uruchomieniu aplikacji to działa dobrze. Używam Nunit 2.6.3 z rehaper test runner.

var httpSessionStateBefour = System.Web.HttpContext.Current.Session; 
var Person= await Db.Persons.FirstOrDefaultAsync(); 
var httpSessionStateAfter = System.Web.HttpContext.Current.Session; 

Jak rozwiązać ten problem?

To jak ja mock HttpContext

HttpContext.Current = Fakes.FakeHttpContext();    
HttpContext.Current.Session.Add("IsUserSiteAdmin", true); 
HttpContext.Current.Session.Add("CurrentSite", null); 

public static class Fakes 
{ 
    public static HttpContext FakeHttpContext() 
    { 
     var httpRequest = new HttpRequest("", "http://stackoverflow/", ""); 
     var stringWriter = new StringWriter(); 
     var httpResponce = new HttpResponse(stringWriter); 
     var httpContext = new HttpContext(httpRequest, httpResponce); 

     var sessionContainer = new HttpSessionStateContainer("id", new SessionStateItemCollection(), 
      new HttpStaticObjectsCollection(), 10, true, 
      HttpCookieMode.AutoDetect, 
      SessionStateMode.InProc, false); 

     httpContext.Items["AspSession"] = typeof (HttpSessionState).GetConstructor(
      BindingFlags.NonPublic | BindingFlags.Instance, 
      null, CallingConventions.Standard, 
      new[] {typeof (HttpSessionStateContainer)}, 
      null) 
      .Invoke(new object[] {sessionContainer}); 

     return httpContext; 
    } 
} 

Answer 1

HttpContext.Current jest uważany za dość straszny własności do pracy z; nie zachowuje się poza domem ASP.NET. Najlepszym sposobem na naprawienie kodu jest zaprzestanie patrzenia na tę właściwość i znalezienie sposobu wyizolowania jej z testowanego kodu. Na przykład można utworzyć interfejs reprezentujący dane bieżącej sesji i udostępnić ten interfejs testowanemu komponentowi, z implementacją wymagającą kontekstu HTTP.

---

Główny problem związany jest z działaniem HttpContext.Current. Ta właściwość jest "magiczna" w środowisku ASP.NET, ponieważ jest unikalna dla operacji żądanie-odpowiedź, ale przeskakuje między wątkami, ponieważ wymaga tego wykonanie - jest selektywnie współużytkowana między wątkami.

Gdy używasz HttpContext.Current poza rurociągiem przetwarzania ASP.NET, magia znika. Po przełączeniu wątków takich jak tutaj, z asynchronicznym stylem programowania, właściwość ta jest kontynuowana po upływie null.

Jeśli absolutnie nie możesz zmienić kodu, aby usunąć trudną zależność od HttpContext.Current, możesz oszukać ten test, wykorzystując kontekst lokalny: wszystkie zmienne w zasięgu lokalnym, gdy deklarujesz kontynuację, są udostępniane dla kontekstu kontynuacji .

// Bring the current value into local scope. 
var context = System.Web.HttpContext.Current; 

var httpSessionStateBefore = context.Session; 
var person = await Db.Persons.FirstOrDefaultAsync(); 
var httpSessionStateAfter = context.Session; 

Żeby było jasne, to będzie tylko praca dla swojej obecnej sytuacji. Jeśli wprowadzisz przed sobą inny kod w postaci await, kod zostanie nagle przerwany; jest to szybka i brudna odpowiedź, którą zachęcam do zignorowania i opracowania bardziej niezawodnego rozwiązania.

Answer 2

Po pierwsze, zalecam odizolowanie kodu tak bardzo, jak to możliwe od HttpContext.Current; nie tylko spowoduje, że twój kod będzie bardziej testowalny, ale pomoże ci przygotować się do ASP.NET vNext, który jest bardziej podobny do OWIN (bez HttpContext.Current).

Jednak może to wymagać wielu zmian, na które być może nie jesteś jeszcze gotowy. Aby poprawnie kpić HttpContext.Current, musisz zrozumieć, jak to działa.

HttpContext.Current to zmienna na wątek kontrolowana przez ASP.NET SynchronizationContext.Ten SynchronizationContext jest "kontekstem żądania", reprezentującym bieżące żądanie; jest tworzony przez ASP.NET, gdy pojawia się nowe żądanie. Mam MSDN article on SynchronizationContext, jeśli chcesz uzyskać więcej szczegółów.

Jak wyjaśniam w mojej async intro blog post, kiedy awaitTask, domyślnie będzie uchwycić bieżący „kontekst” i używać, aby wznowić metodę async. Gdy metoda async działa w kontekście żądania ASP.NET, "kontekst" przechwycony przez await to ASP.NET SynchronizationContext. Po wznowieniu metody async (prawdopodobnie na innym wątku) program ASP.NET SynchronizationContext ustawi HttpContext.Current przed wznowieniem metody async. Tak działa async/await w hoście ASP.NET.

Teraz, po uruchomieniu tego samego kodu w teście jednostki, zachowanie jest inne. W szczególności nie ma programu ASP.NET SynchronizationContext do ustawienia HttpContext.Current. Zakładam, że twoja metoda testu jednostkowego zwraca Task, w którym to przypadku NUnit w ogóle nie dostarcza SynchronizationContext. Tak więc, po wznowieniu metody async (prawdopodobnie na innym wątku), jej numer HttpContext.Current może nie być taki sam.

Istnieje kilka sposobów na rozwiązanie tego problemu. Jedną z opcji jest napisanie własnego SynchronizationContext, który zachowuje HttpContext.Current, tak jak robi to program ASP.NET. Łatwiejszą (ale mniej wydajną) opcją jest użycie a SynchronizationContext that I wrote called AsyncContext, która zapewnia, że ​​metoda async zostanie wznowiona w tym samym wątku. Powinieneś być w stanie zainstalować my AsyncEx library from NuGet, a następnie owiń swoje metody testowania jednostek w rozmowie na AsyncContext.Run. Należy zauważyć, że metody badań są obecnie jednostka synchroniczna:

[Test] 
public void MyTest() 
{ 
    AsyncContext.Run(async() => 
    { 
    // Test logic goes here: set HttpContext.Current, etc. 
    }); 
} 

Answer 3

przyszedłem na to pytanie, gdy o problem w moim kod ... gdzie HttpContext.Current jest zerowy po czekają w Async MVC Akcji. Opublikuję to tutaj, ponieważ inni jak ja mogą tu wylądować.

Moja generalna rekomendacja to zgarnięcie wszystkiego, co chcesz z sesji, do zmiennej lokalnej, podobnie jak inne powyżej omówione, ale nie martw się utrzymaniem kontekstu, a zamiast tego martw się tylko chwytaniem rzeczywistych przedmiotów, które chcesz.

public async Task<ActionResult> SomeAction(SomeModel model) 
{ 
int id = (int)HttpContext.Current.Session["Id"]; 

/* Session Exists Here */ 

var somethingElseAsyncModel = await GetSomethingElseAsync(model); 

/* Session is Null Here */ 

// Do something with id, thanks to the fact we got it when we could 
}