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

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)

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.

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.

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.

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 .