2009-07-06 16 views
10

Actualización:Mejores prácticas para HttpContext y controladores comprobables en ASP.Net MVC

Sobre la base de un par de las respuestas que he recibido, sólo quiero dejar claro que soy muy consciente de cómo hacer para burlarse HttpContext utilizando un marco de burla. Estoy más interesado en saber cuáles son los pros y los contras de burlarse de HttpContext en comparación con el uso de clases de contenedor en HttpContext.


Busco opiniones sobre cómo hacer frente a la hora de construir HttpContext controladores comprobables en ASP.Net MVC. Después de leer sobre él, parece haber dos escuelas de pensamiento, ya sea que se basan en HttpContextBase y usan un marco burlón para generar los stubs/mocks necesarios para las pruebas de su unidad o compilar clases agnósticas en las áreas de HttpContext que piensa utilizar .

Ahora me inclino por construir fuera de HttpContextBase. Parece que es tanto el proceso de desarrollo más rápido y más fácil de mantener, ya que no tiene que perder tiempo desarrollando y manteniendo clases de contenedor adicionales. Puedo ver cómo las clases contenedoras pueden ser beneficiosas, ya que abstraen la implementación subyacente y mantienen el contexto del controlador separado de la solicitud, pero no estoy seguro de si vale la pena el gasto extra para configurarlo y mantenerlo.

¿Cuáles cree que son los pros y los contras entre estos dos enfoques y cuándo elegiría uno sobre el otro? ¿Existen ciertos tipos de desarrollo que se presten a una de las soluciones más que a la otra?

Como parece un problema común la mayoría de los equipos que realizan pruebas unitarias y que usan ASP.Net MVC tienen que lidiar, ¿cómo se las arreglaron para manejar este problema? Si ha abordado este problema, ¿cómo funcionó su solución y qué haría de manera diferente ahora?

Respuesta

6

Me estoy inclinando hacia HttpContextBase. Principalmente porque creo que fue inventado por esta razón: capacidad de prueba. Y por qué reinventar la rueda cuando ya existe una solución aceptable.

Si se pone un gran esfuerzo en sus clases de envoltura alrededor HttpContext, acabaría con algo muy similar a HttpContextBase ...

1

Para las pruebas utilizo Rhino.Mocks. Para configurar el HttpContext en el controlador, simplemente me burlé de él. Así que mi sistema bajo prueba (o IVU) es algo así como:

  Controller controllerBase = sut as Controller; 

entonces me burlo a cabo el contexto regulador, y estableció el contexto en el contexto del controlador para devolver el simulacro de la clase HttpContextBase (como he mencionado anteriormente) Mi código se parece a algo como:

controllerContext = AMockOf<ControllerContext>(); 

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

Para otros objetos a veces uso falsificaciones también.

+0

¿Cómo ha sido su experiencia con esta configuración? ¿Has encontrado que es mantenible, viable, etc.? –

+0

Sí, me funcionó muy bien. El truco es esconderlo todo en una clase base de la que sus clases de prueba heredan, por lo que lo hace una vez y no tiene que preocuparse por ello de nuevo. – Erik

Cuestiones relacionadas