2009-07-06 16 views
10

Aggiornamento:Best practice per HttpContext e controller verificabili in ASP.Net MVC

Sulla base di un paio di risposte che ho ricevuto, voglio solo mettere in chiaro che sono ben consapevole di come fare per beffardo HttpContext utilizzando una struttura di simulazione. Sono più interessato a sapere quali sono i pro e i contro di deridere HttpContext rispetto all'utilizzo di classi wrapper attorno a HttpContext.


sto cercando pareri su come trattare con HttpContext quando si costruisce controllori testabili in ASP.Net MVC. Dopo averlo letto, ci sono due scuole di pensiero, che si basano su HttpContextBase e usano un framework di simulazione per generare gli stub/mock necessari per il test dell'unità o per creare classi di wrapper agnostici attorno alle aree di HttpContext che si intende utilizzare .

In questo momento sono propenso a costruire HttpContextBase. Sembra che sia il processo di sviluppo più veloce e più facile da mantenere, poiché non è necessario perdere tempo a sviluppare e mantenere classi di wrapper aggiuntive. Riesco a vedere come le classi wrapper potrebbero essere utili in quanto estrapolano l'implementazione sottostante e mantengono il contesto del controllore separato dalla richiesta, ma non sono sicuro che ciò valga il costo aggiuntivo da configurare e mantenere.

Quali sono i pro e i contro tra questi due approcci e quando sceglieresti l'uno rispetto all'altro? Esistono alcuni tipi di sviluppo che si prestano ad una delle soluzioni più dell'altra?

Dato che questo sembra un problema comune, la maggior parte dei team che eseguono test unitari e utilizzano ASP.Net MVC devono occuparsi di come gestire o risolvere questo problema. Se hai affrontato questo problema, come funziona la tua soluzione e cosa faresti diversamente ora?

risposta

6

Sono inclinato verso HttpContextBase. Soprattutto perché penso che sia stato inventato proprio per questo: testabilità. E perché reinventare la ruota quando c'è già una soluzione accettabile.

Se si mette un sacco di fatica nelle vostre classi wrapper intorno HttpContext, che ci si finisce con qualcosa di molto simile a HttpContextBase ...

1

Per il test, utilizzo Rhino.Mocks. Per configurare HttpContext nel controller, l'ho semplicemente deriso. Quindi il mio sistema in prova (o SUT) è qualcosa di simile:

  Controller controllerBase = sut as Controller; 

Ho poi rido il contesto di controllo, e impostare il contesto sul contesto controller per restituire la finta della classe HttpContextBase (come ho già detto). Il mio codice è simile al seguente:

controllerContext = AMockOf<ControllerContext>(); 

// Add the test HttpContextBase to the controller context 
HttpContextBase httpContextBase = SetUpTestHttpContext(); 
WhenThe(controllerContext).IsAskedForIts(x =>x.HttpContext).Return(httpContextBase).Repeat.Any(); 

Per altri oggetti a volte uso anche i falsi.

+0

Come stata la tua esperienza con questa configurazione? Hai trovato che sia mantenibile, lavorabile, ecc.? –

+0

Sì, ha funzionato molto bene per me. Il trucco è nasconderlo tutto in una classe base da cui ereditano le classi di test, quindi fallo una volta e non devi preoccuparti di nuovo. – Erik

Problemi correlati