Perché simulare HttpContext se può essere costruito?

Question

Ho sempre simulato/fustigato/stappando HttpContext in qualche modo in ASP.NET (molto più facile in ASP.NET MVC/MonoRail).

Ma posso vedere che HttpContext stesso può essere costruito facilmente, letteralmente con un paio di linee di codice.

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

Se ci avvolgiamo il codice in qualcosa come questo dovrebbe funzionare bene, e probabilmente si può anche rendere ASPX utilizzando tale:

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

Quindi le domande sono:

1. Motivi per cui NON dovrebbe essere fatto.
2. Ragioni per le quali DOVREBBE essere fatto.
3. Perché non è ampiamente utilizzato (in effetti non ricordo NESSUN post su di esso).

Ricordo un post in cui Phill Haack ha costruito HttpContext utilizzando gli hack di Reflection.
Ma sembra che non sia proprio necessario.

Cheers,
Dmitriy.

Answer 1

Va bene per fare test molto semplici, ma come testare un componente che usa HttpRequest.Files? Per quanto ne so, non ci sono API pubbliche che ti consentano di specificarlo su SimpleWorkerRequest. Anche se potresti trovare una posizione in cui puoi impostare una proprietà HttpFileCollection, nota che il suo costruttore è interno, quindi non puoi nemmeno creare un'istanza di quel tipo.

HttpRequest.Files non è sola in questo senso, e in effetti ci sono probabilmente molte più cose che non può test con l'attuazione HttpContext corrente di quanto si può test. È qui che le astrazioni diventano davvero utili.

Answer 2

Ci sono un paio di scenari da considerare.

Scenario uno: test dell'unità. hai qualcosa di piccolo, come una classe che gestisce l'accesso alla cache e che chiama HttpContent.Cache esplicitamente. In questo caso, prendi in giro il contesto in modo da poter vedere quali chiamate sono state fatte e se stanno funzionando.

Scenario due: si sta eseguendo un test di integrazione, in cui si sta tentando di testare qualcosa di grande come la generazione di una pagina complessa. In questo caso, dagli il vero oggetto HttpContent come hai trovato. Il tuo test di integrazione simulerà meglio il runtime reale.

Answer 3

che potrebbe funzionare, ma ...

• Innanzitutto vedo alcuni percorsi, che potrebbero essere diversi in ambienti.
• In secondo luogo, ha bisogno di qualcosa come IIS installato?
• Quanto tempo ci vuole per crearlo? Se ho 100 test che ne hanno bisogno e ci vuole 1 sec, questo significa che il mio test dura circa un minuto o più e porta gli sviluppatori a eseguire test meno.
• Con quale semplicità è possibile simulare/configurare la cache, la richiesta ecc. Per creare uno scenario di test?

Il mocking/stubing è probabilmente più semplice.

EDIT

trovato un po 'di codice sorgente per HttpContext e SimpleWorkerRequest nel progetto Mono:

• SimpleWorkerRequest.cs
• HttpContext.cs

Questi possono dare una migliore comprensione ciò che sta accadendo nella creazione .

trovato un articolo che potrebbe essere utile pure: ASP.NET CreateApplicationHost/SimpleWorkerRequest API Hole

Che in realtà illustra bene che abbiamo bisogno di capire cosa sta succedendo in quelli oggetto prima di applicarle e ci vuole tempo. Il derisione sembra più facile.