2009-11-06 9 views
7

Siempre he estado fingiendo/burlando/pegando HttpContext de alguna manera en ASP.NET (mucho más fácil en ASP.NET MVC/MonoRail).¿Por qué simular HttpContext si se puede construir?

Pero puedo ver que HttpContext se puede construir fácilmente, literalmente, con un par de líneas de código.

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

Si terminaremos este código en algo como esto debería funcionar bien, y probablemente incluso puede hacer utilizando ASPX que:

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

Así que las preguntas son:

  1. Razones por las que NO se debe hacer.
  2. Razones por las que DEBERÍA hacerse.
  3. Por qué no se usa ampliamente (de hecho, no recuerdo NINGUNA publicación al respecto).

Recuerdo una publicación en la que Phill Haack construyó HttpContext utilizando Reflection hacks.
Pero parece que simplemente no es necesario.

Cheers,
Dmitriy.

Respuesta

5

Está bien para hacer pruebas muy simples, pero ¿cómo probarías un componente que utiliza HttpRequest.Files? Por lo que sé, no hay API públicas que te permitan especificar esto en SimpleWorkerRequest. Incluso si pudiera encontrar una ubicación donde pudiera establecer una propiedad HttpFileCollection, tenga en cuenta que su constructor es interno, por lo que ni siquiera puede crear una instancia de ese tipo.

HttpRequest.Files no está solo en este sentido, y de hecho es probable que haya mucho más cosas que no puede prueba con la aplicación HttpContext corriente de lo que puede prueba. Aquí es donde las abstracciones realmente son útiles.

2

Hay un par de situaciones a considerar.

Escenario uno: Usted está realizando pruebas unitarias. tiene algo pequeño, como una clase que gestiona el acceso al caché, y que llama a HttpContent.Cache explícitamente. En este caso, simule el contexto para que pueda ver qué llamadas se están realizando y si están funcionando como espera.

Escenario dos: Está realizando una prueba de integración, donde intenta probar algo grande como la generación de una página compleja. En este caso, dele el objeto HttpContent real de la manera que ha encontrado. Su prueba de integración simulará mejor el tiempo de ejecución real.

+0

burlarse también es excelente para acceder a condiciones de error específicas. – dbn

0

que podría funcionar, pero ...

  • En primer lugar me ver algunas rutas, que pueden ser diferentes en entornos.
  • En segundo lugar, ¿necesita algo como IIS instalado?
  • ¿Cuánto tiempo se tarda en crearlo? Si tengo 100 pruebas que lo necesitan y demora 1 segundo, eso significa que mi prueba durará aproximadamente un minuto o más y esto lleva a los desarrolladores a realizar menos pruebas.
  • ¿Con qué facilidad puede simular/configurar caché, solicitar etc. para crear un escenario de prueba?

Mocking/stubbing es probablemente más fácil.

EDITAR

encontrado algo de código fuente para HttpContext y SimpleWorkerRequest en proyecto Mono:

Estos pueden dar una mejor idea de lo que está sucediendo en la creación .

encontrado un artículo lo que podría ser útil también: ASP.NET CreateApplicationHost/SimpleWorkerRequest API Hole

Que en realidad ilustra muy bien que tenemos que entender lo que está sucediendo en los objetos antes de aplicarlos y se necesita tiempo. Burlarse parece más fácil.

+0

CAMINOS: No creo que realmente estén en uso. IIS: no creo que sea necesario también. TIEMPO DE CREAR: Supongo que no debería ser más largo que cualquier objeto complejo. Pero el último punto (maqueta Caché/Solicitud) es bueno. –

Cuestiones relacionadas