2008-11-27 7 views
6

Im intentando generar vistas en pruebas unitarias pero no puedo evitar el VirtualPathProvider faltante. La mayoría de los viewengines utilizan la clase base VirtualPathProviderViewEngine que obtiene el proveedor del entorno de alojamiento actual.¿Cómo se pueden generar vistas en las pruebas de la unidad asp.net-mvc?

protected VirtualPathProvider VirtualPathProvider { 
    get { 
     if (_vpp == null) { 
      _vpp = HostingEnvironment.VirtualPathProvider; 
     } 
     return _vpp; 
    } 
    set { 
     _vpp = value; 
    } 
} 

En las pruebas unitarias no hay HostingEnvironment, incluso si creo uno no hay VirtualPathProvider actual.

¿Cómo puedo solucionar este problema? ¿Debo crear un FakeWebFormViewEngine personalizado?

+0

¿Alguna vez encontró una respuesta a esto? Estoy en contra del mismo problema :-) –

+0

Octubre de 2012. Incluso con todos los comentarios que se reducen a "¡lo estás probando mal!", Uno podría estar interesado en probar los mecanismos que dependen de VirtualPathProvider. Entonces, solo curiosidad: ¿alguien llegó allí? –

Respuesta

0

Traté de hacer esto también. Lamentablemente, no es solo VirtualPathProvider (VPP) el problema. El VPP se utiliza para asignar la vista o vista parcial a una ruta física para determinar la existencia del archivo. Desafortunadamente, ViewContext termina con el camino virtual, no con la ruta física, por lo que cuando se representa la vista, el generador usa propiedades de HostingEvnironment que no existe.

Si está utilizando una versión de Visual Studio con Testing, entonces podría usar una prueba de unidad web. Esto le permitirá usar el navegador para llamar a la URL y luego analizar la respuesta para verificar los valores.

0

Disculpe si esto suena ignorante, pero ¿cuál es el propósito de generar vistas? Puede que me esté perdiendo algo, pero el enfoque principal de las pruebas unitarias es "probar la unidad". En una aplicación ASP.NET MVC configurada correctamente, el código que debe probarse está en el controlador y debajo. De hecho, diría que, si está bien desarrollado, está debajo.

La prueba de la vista es una prueba de aceptación del usuario. No veo nada de malo con la automatización de esto, de ninguna manera, pero no estoy seguro de que esto sea algo que tenga que hacerse con una prueba unitaria.

¿Echo de menos algo?

+0

Estoy de acuerdo, pero hay algunos escenarios en los que una prueba de unidad es útil, creo. Hay motores de vista que permiten "secuencias de comandos" dentro de las vistas (chispa), algunas pruebas simples para probar estas funciones sería genial, creo. No me malinterprete, no quiero comparar el código HTML generado, es más como "¿está visible el formulario de inicio de sesión?" cosas. –

2

Hay características que vienen en VS Team System 2010 para las Pruebas de aceptación que serían apropiadas para lo que está tratando de hacer. Como menciona Gregory A Beamer, las pruebas de unidad para MVC se hacen al controlador. También puede probar el modelo según cómo implemente su modelo.

Aquí es donde hay mucha controversia. Algunas personas miran el modelo como entidades comerciales donde las veo como representaciones del modelo específico de la Vista. Más de un modelo de vista. Como no hay una funcionalidad real en mi modelo, no tengo que probarlo. Pruebo mi DAL, Business Logic Layer fuera del MVC. MVC realmente es parte de la capa de presentación. Es capas de su presentación, no su aplicación. Aún capas tu aplicación.

En lo que respecta a las pruebas unitarias, el controlador es donde realiza la prueba. Puede probar su modelo si hay métodos que requieren pruebas. En cuanto a las vistas, los usuarios las prueban por aceptación o mediante la automatización como Watin.

0

Puede probar Ivonna para la integración (y, hasta cierto punto, la unidad) probando sus Vistas.

Cuestiones relacionadas