Dlaczego makiety HttpContext, jeśli można go zbudować?

Question

Zawsze udawałem/kpiąłem/odcinałem HttpContext jakoś w ASP.NET (o wiele łatwiej w ASP.NET MVC/MonoRail).

Ale widzę, że sam HttpContext może być skonstruowany z łatwością, dosłownie za pomocą kilku linii kodu.

var tw = new StringWriter(); 
var workerReq = new SimpleWorkerRequest("/webapp", @"c:\here\there\wwwroot", "page.aspx", tw); 
var context = new HtpContext(workerReq); 

Jeśli będziemy zawijać ten kod na coś takiego powinno działać dobrze i pewnie możemy nawet czynią ASPX użyciem że:

using(Simulate.HttpContext()) { 
    HttpContext.Current.BlaBla; 
} 

więc pytania są:

1. Powody, dla których NIE należy tego robić.
2. Powody, dla których należy ZROBIĆ.
3. Dlaczego nie jest powszechnie używany (w rzeczywistości nie pamiętam żadnych wpisów na ten temat).

Pamiętam jeden post, w którym Phill Haack skonstruował HttpContext za pomocą hacków Reflection.
Ale wydaje się, że to nie jest potrzebne.

Pozdrawiam,
Dmitrij.

Answer 1

Jest to w porządku do wykonywania bardzo prostych testów, ale w jaki sposób jednostka testowałaby składnik, który korzysta z HttpRequest.Files? O ile mi wiadomo, nie ma publicznych interfejsów API, które umożliwiałyby określenie tego w SimpleWorkerRequest. Nawet jeśli można znaleźć lokalizację, w której można ustawić właściwość HttpFileCollection, należy pamiętać, że jej konstruktor jest wewnętrzny, więc nie można nawet utworzyć instancji tego typu.

HttpRequest.Files nie jest sam w tym zakresie, aw rzeczywistości są prawdopodobnie znacznie więcej rzeczy, które nie mogątestu z bieżącą realizacją HttpContext niż ty może testu. To tutaj naprawdę przydatne są abstrakcje.

Answer 2

Istnieje kilka scenariuszy do rozważenia.

Scenariusz pierwszy: Testujesz urządzenie. masz coś małego, jak klasa zarządzająca dostępem do pamięci podręcznej i która wywołuje jawnie HttpContent.Cache. W takim przypadku możesz sfałszować kontekst, aby zobaczyć, jakie połączenia są tworzone i czy działają zgodnie z oczekiwaniami.

Scenariusz drugi: Przeprowadzasz test integracji, w którym próbujesz przetestować coś dużego, jak generowanie złożonej strony. W takim przypadku nadaj mu rzeczywisty obiekt HttpContent w taki sposób, w jaki został znaleziony. Twój test integracji lepiej zasymuluje rzeczywisty czas wykonywania.

Answer 3

To może działać, ale ...

• pierwsze widzę pewne ścieżki, które mogą być różne w środowisku.
• Po drugie, czy potrzebuje czegoś takiego jak IIS?
• Ile czasu potrzeba na jego utworzenie? Jeśli mam 100 testów, które go potrzebują i zajmuje to 1 sekundę, oznacza to, że mój test jest uruchamiany o minutę lub dłużej, co prowadzi do tego, że programiści testują mniej.
• Jak łatwo można sfałszować/ustawić pamięć podręczną, zażądać itp. W celu utworzenia scenariusza testowego?

Szarpanie/stubowanie jest prawdopodobnie łatwiejsze.

EDIT

Znaleziono jakiś kod źródłowy HttpContext i SimpleWorkerRequest w projekcie Mono:

• SimpleWorkerRequest.cs
• HttpContext.cs

Ci mogą dać lepszy wgląd co dzieje się w tworzeniu .

Znaleziono artykuł, co może być pomocne, a także: ASP.NET CreateApplicationHost/SimpleWorkerRequest API Hole

To rzeczywiście ładnie ilustruje, że musimy zrozumieć, co się dzieje w tych obiektów przed ich zastosowaniem, a to wymaga czasu. Kpiny wydają się łatwiejsze.