¿Por qué está mal visto probar MVC Views?

23

Actualmente estoy estableciendo las bases para una aplicación ASP.Net MVC y estoy investigando qué tipo de pruebas unitarias debería estar preparado para escribir. He visto en varios lugares a personas que esencialmente dicen 'no te molestes en probar tus puntos de vista, no hay lógica y es trivial y será cubierto por una prueba de integración'.

No entiendo cómo esto se ha convertido en la sabiduría aceptada. Las pruebas de integración tienen un propósito completamente diferente que las pruebas unitarias. Si rompo algo, no quiero saber media hora más tarde cuando se rompen mis pruebas de integración, quiero saber de inmediato.

Escenario de muestra: Digamos que estamos tratando con una aplicación CRUD estándar con una entidad del Cliente. El cliente tiene un nombre y una dirección. En cada nivel de prueba, quiero verificar que la lógica de recuperación del Cliente obtenga el nombre y la dirección correctamente.

Para realizar una prueba unitaria del repositorio, escribo una prueba de integración para acceder a la base de datos. Para realizar una prueba unitaria de las reglas comerciales, me burlo del repositorio, alimento los datos apropiados de las reglas comerciales y verifico que se devuelvan mis resultados esperados.

Lo que me gustaría hacer: para realizar una prueba unitaria de la interfaz de usuario, me burlo de las reglas de negocio, configuro mi instancia de cliente esperada, renderizo la vista y verifico que la vista contenga los valores apropiados para la instancia que especifiqué.

Lo que estoy atascado: para realizar una prueba unitaria del repositorio, escribo una prueba de integración, configuro un inicio de sesión apropiado, creo los datos requeridos en la base de datos, abro un navegador, navego hasta el cliente y verifico que la página resultante contenga valores para la instancia que especifiqué.

Me doy cuenta de que hay una superposición entre los dos escenarios discutidos anteriormente, pero la diferencia clave es el tiempo y el esfuerzo necesarios para configurar y ejecutar las pruebas.

Si yo (u otro desarrollador) elimina el campo de dirección de la vista, no quiero esperar a que la prueba de integración descubra esto. Quiero que se descubra y se marque en una prueba unitaria que se obtiene varias veces al día.

Tengo la sensación de que simplemente no estoy captando algún concepto clave. ¿Alguien puede explicar por qué desear comentarios de prueba inmediatos sobre la validez de una vista MVC es algo malo? (o si no está mal, entonces no es la forma esperada de obtener dichos comentarios)

unit-testing asp.net-mvc

— Peter Bernier
fuente

1

"To unit-test the repository, I write an integration test"¿Esperar lo? Esa no es una prueba unitaria del repositorio. Está automatizando la prueba, pero el código bajo prueba aún incluye el DAL y la base de datos. Para realizar una prueba unitaria del repositorio que tiene, lo aísla como lo hace para sus reglas comerciales.

— StuperUser

La prueba unitaria de la vista representada como se espera es solo una prueba unitaria de que su motor de plantillas funciona. Es como si la unidad probara que su C compilado contiene ciertos fragmentos de código de máquina, su unidad prueba el compilador, no su código.

— Raynos

2

@Raynos Respetuosamente, voy a tener que estar en desacuerdo. Si yo (u otro desarrollador) conecta erróneamente la interfaz de usuario para representar un atributo de datos en el campo de la interfaz de usuario para otro (por ejemplo, 'Nombre' en el 'Campo de apellido', eso no tiene nada que ver con el motor de plantillas, ni se trata de un tema o DAL BR .. es claramente un problema que sólo se expuso en la vista.

— Peter Bernier

1

@PeterBernier tiene un buen punto, pero me resulta difícil definir la línea entre "probar si el compilador funciona" y "probar si mi código funciona". Sin mencionar que las pruebas para la interfaz de usuario están estrechamente relacionadas con la interfaz de usuario. Cualquier cambio en la interfaz de usuario hace que las pruebas fallen. Realmente no se puede realizar ningún tipo de refactorización de la interfaz de usuario sin que falle una prueba.

— Raynos

9

Las pruebas de IU simples son bastante fáciles en ASP.NET MVC. Esencialmente, todo lo que tiene que hacer es afirmar que el HTML devuelto contiene los elementos que necesita. Si bien esto garantiza que la página HTML esté estructurada de la manera esperada, no prueba completamente la IU.

La prueba adecuada de la interfaz de usuario web requiere una herramienta como Selenium que utilizará navegadores en su máquina y garantizará que JavaScript y HTML funcionen correctamente en todos los navegadores. Selenium tiene un modelo de cliente / servidor para que pueda tener un conjunto de máquinas virtuales con clientes Unix, Mac y Windows y el conjunto de navegadores comunes a esos entornos.

Ahora, una aplicación MVC (patrón, no marco) bien diseñada pone la lógica importante en los modelos y controladores. En resumen, la funcionalidad de la aplicación se prueba cuando prueba esos dos aspectos. Las vistas tienden a tener solo lógica de visualización y se verifican fácilmente con inspección visual. Debido al escaso procesamiento en la vista y la gran parte de la aplicación que se está probando bien, muchas personas no piensan que el dolor de probar la capa de vista supera el beneficio obtenido por ella.

Dicho esto, MVC tiene algunas buenas instalaciones para verificar el DOM devuelto por la solicitud. Eso reduce el dolor bastante para probar la capa de vista.

— Berin Loritsch
fuente

1

"Esencialmente, todo lo que tiene que hacer es afirmar que el HTML devuelto contiene los elementos que necesita". Esto es exactamente lo que estoy tratando de hacer y está resultando no ser trivial. ¿Puede señalar un enlace donde funcione con una acción de controlador específica en lugar de simplemente representar un control? (He trabajado en un par de escritos, pero RenderPartial no está logrando lo que quiero hacer sin una sobrecarga significativa ...)

— Peter Bernier

Querrá consultar mvccontrib.codeplex.com (MVC Contrib). Esto proporciona ayuda que no estaba integrada en el lenguaje central, y se recomendó en el libro "Test-Drive ASP.NET MVC" (programadores pragmáticos). Sin embargo, sigo pensando que Selenium es una mejor opción para las pruebas de View.

— Berin Loritsch

TestHelper (MVC Contrib): mvccontrib.codeplex.com/…

— Berin Loritsch

Selenium (en mi caso Selenium RC) es lo que usaré para mis pruebas de integración. Lo que quiero es que ocurra una falla antes de ese punto.

— Peter Bernier el

2

@Peter: Su comentario acerca de que sus esfuerzos son "no triviales" es exactamente la razón por la cual las vistas de prueba de la unidad están mal vistas. En consecuencia, una estrategia típica es hacer que las vistas sean lo más delgadas posible (es decir, que no contengan lógica de negocios), de modo que la mayoría de las pruebas unitarias puedan tener lugar en otro lugar (generalmente en ViewModel). Las vistas en sí pueden verificarse mediante inspección visual o con una herramienta de prueba de interfaz de usuario como Selenium.

— Robert Harvey

7

No diría que está mal visto. Más bien, ese sentimiento es el resultado del hecho de que las vistas de MVC de prueba de unidad (al menos de la variedad aspx) es bastante difícil porque las vistas aspx tienen demasiada dependencia de WebForms, que son bastante inconstables. Entonces, el argumento dice que no vale la pena el esfuerzo porque las opiniones tienden a no ser tan complicadas.

Por supuesto, las vistas pueden ser bastante complicadas, por lo que es su elección.

— marcind
fuente

3

Las vistas de ASP.NET MVC no están vinculadas a los formularios web, que yo sepa. ¿No es uno de los puntos importantes para ASP.NET MVC que no son formularios web?

— Adam Lear

Mi punto de vista es que se necesita más esfuerzo humano para escribir las pruebas de integración para cubrir la interfaz de usuario, que escribir verdaderas 'pruebas unitarias' para cubrir las vistas. Es por eso que estoy tratando de entender algo de la resistencia que parece existir para escribir pruebas unitarias para las vistas.

— Peter Bernier el

Las vistas de @Anna Aspx se crean sobre WebForms. Se derivan de la System.Web.UI.WebControls.Pageclase, usan <asp:ContentPlaceholder>controles, etc. La forma en que MVC los ejecuta evita gran parte de la canalización de ejecución de la página típicamente asociada con WebForms, pero aún usa muchas cosas de WebForms debajo de las cubiertas.

— Marcind

Si usa un motor de visualización diferente (como una maquinilla de afeitar), debería poder alejarse más del motor de Webforms.

— The Muffin Man

6

No estoy seguro de que esté mal visto. La capacidad de prueba es uno de los beneficios clave del uso de ASP.NET MVC. Consulte el blog de Steve Sanderson para obtener más información al respecto.

También escribió el mejor libro ASP.MVC (IMO). No solo enseña MVC, sino que va más allá para enseñar las mejores prácticas a su alrededor, incluidas las prácticas de prueba.

Estoy pensando que necesito aclarar un poco las vistas de prueba de unidad: puede crear pruebas de unidad alrededor del resultado devuelto por el controlador (ActionResult, etc.). Aún tendrá que hacer otras pruebas para la interfaz de usuario real y la interacción de la interfaz de usuario.

— Mark Freedman
fuente

"Todavía tendrá que hacer otras pruebas para la interfaz de usuario y la interacción de la interfaz de usuario". Ese es exactamente mi punto de la pregunta ... ¿por qué las pruebas de IU de repente se convierten en parte de 'otras pruebas' (es decir, pruebas de integración)? Había visto una gran cantidad de contenido de Steve Sanderson y eso es lo que me ayudó a comenzar por este camino, básicamente tratando de replicar lo que está haciendo con su proyecto 'MvcFakes' y encontrándome con problemas con su código escrito para versiones anteriores de MVC. .

— Peter Bernier

1

Puede aprender cómo probar la Vista devuelta por una acción del controlador, cómo probar los Datos de la Vista devueltos por una acción del controlador, y cómo probar si una acción del controlador lo redirige o no a una segunda acción del controlador consultando la siguiente URL, describa en este breve artículo sobre Prueba de datos de vista en MVC .

— Jaypee
fuente