¿Es Unit Testing el objetivo principal del patrón MVC?

14

Recientemente en una entrevista, una de las preguntas fue '¿Por qué usamos MVC?' ¡Acabo de responder que está mucho más cerca de cómo están muchos de los sistemas del mundo real! Explicaron los beneficios que tiene cuando se trata de Mantenimiento, Escalabilidad, etc. Pero no estaban convencidos y finalmente me dijeron que MVC se usa principalmente ya que "permite pruebas unitarias fáciles".

Si bien sé que es un punto válido, aún dudo si es la razón principal porque (i) incluso si decido no escribir Casos de prueba unitarios, MVC es una opción probable (ii) Muchos sistemas GUI donde hay Casos de prueba unitarios no existen seguir MVC.

Entonces, la pregunta es '¿La prueba de unidad es el objetivo principal del patrón MVC?'

EDITAR: Supongo que podrían estar mencionando la facilidad del desarrollo impulsado por pruebas / escribir NUnit Testcases. Esto se debe a que podemos escribir casos de prueba para el Modelo (siempre que la Vista refleje exactamente los cambios de estado del Modelo). Por favor, corríjame si estoy equivocado.

mvc

— WinW
fuente

11

No pasaste la entrevista, ¿verdad? Si no, que suerte tienes. No me uniré a una empresa que tiene una mentalidad muy equivocada desde el principio. :) Pruebas unitarias Definitivamente no es el objetivo principal. Puede ayudar a las pruebas unitarias porque la preocupación está separada, pero definitivamente no es el objetivo principal.

— Rudy

44

Recuerde que la entrevista funciona en ambos sentidos. Los estás probando tanto como a ti. Acabas de recibir una bandera roja: no entres en esta empresa. No tienen idea, pero aún peor, piensan que no se dan cuenta de eso, así que no hay esperanza de mejorar. Si elige ir en la empresa, enfrentará muchas situaciones kafkaescas.

— deadalnix

@Rudy No, no aprobé: P, era el Centro de Desarrollo de un banco de inversión líder. También los chicos se veían bien y muy auténticos con otras preguntas y es por eso que me confundí con esto.

— WinW

@deadalnix, Sí, cierto ... siento lo mismo después de ver las respuestas aquí. Pero no estaba tan seguro antes de publicarlo aquí.

— WinW

Estoy totalmente de acuerdo con deadalnix. No vayas a esta empresa.

— Rudy

33

El objetivo principal sería la "separación de preocupaciones", ya que el modelo, la vista y el controlador tienen responsabilidades distintas.

El autor del artículo original de Xerox PARC afirma que:

El propósito esencial de MVC es cerrar la brecha entre el modelo mental del usuario humano y el modelo digital que existe en la computadora.

Si las pruebas unitarias fueran el objetivo principal, uno sería capaz de ver fácilmente las vistas unitarias. Una mirada al panorama de los proyectos / marcos de pruebas unitarias revelaría que es bastante contrario a la afirmación realizada. Normalmente, se utilizarían pruebas funcionales y de integración para probar la vista.

— Vineet Reynolds
fuente

2

Diría que los objetivos principales son habilitar la metáfora de manipulación directa (eso es básicamente lo que dice la cita) y el empoderamiento del usuario (originalmente se imaginó que solo los modelos serían escritos por programadores, las vistas y controladores serían escritos por usuarios finales).

— Jörg W Mittag

14

En mi opinión, la respuesta es un firme "no". Quizás este fue el principal beneficio que se observó en esta organización específica, pero no lo llamaría el 'objetivo primario'.

Supongo que no sería tan difícil implementar MVC de una manera, eso es infernalmente difícil de probar en la unidad (diablos, la forma en que lo hice por primera vez era difícil de probar).

Por otro lado, se podría decir que prácticamente cualquier patrón (excluyendo cosas como Singleton) facilita las pruebas unitarias, ya que a menudo promueven el desacoplamiento, pero ¿es su 'objetivo principal'? Apenas.

— Mchl
fuente

12

MVC (al igual que la mayoría de los patrones de diseño conocidos) existía mucho antes de que se conocieran las pruebas unitarias. El libro GoF se publicó en 1994, y solo documentaban los patrones que han estado en uso durante años (si no décadas) antes. (Y no se menciona la prueba de la unidad en él.) Acerca de la prueba de la unidad, no puedo encontrar una hora exacta sobre cuándo se hizo "pública". Lo leí personalmente en artículos relacionados con Extreme Programming y el primer libro de XP. salió en 1999.

Obviamente, las pruebas unitarias no podrían ser el objetivo principal de inventar / documentar patrones, mientras que es justo decir que los patrones, cuando se aplican bien, facilitan enormemente las pruebas unitarias.

— Péter Török
fuente

La referencia de la línea de tiempo es una buena mención, lógicamente apoya el argumento.

— WinW

Parece que hay un pequeño problema con la fecha. heim.ifi.uio.no/~trygver/themes/mvc/mvc-index.html dice "MVC fue concebido en 1978 como la solución de diseño para un problema en particular". No se preocupe ... Aún así su argumento es válido: MVC estuvo allí mucho antes de que se originaran las pruebas unitarias.

— WinW

Las pruebas unitarias han existido desde al menos la década de 1980. Estaba comenzando mi carrera en ese entonces y teníamos pruebas unitarias en algunos de los proyectos en los que trabajé (y no parecía una idea nueva en ese momento). Simplemente no teníamos los marcos preconstruidos que tenemos ahora.

— GreenMatt

2

@GreenMatt, sé que Kent Beck no inventó las pruebas unitarias, simplemente las reutilizó :-) Pero AFAIK era relativamente desconocido antes de XP y Agile comenzó a propagarlas ampliamente.

— Péter Török

@ Péter Török: Recuerdo 1) escribir mi propio código simple para evaluar las funciones individuales desde la universidad (principios de la década de 1980 para mí) y que otra persona me dio la idea; 2) ver representaciones y leer documentos sobre el modelo de cascada en los años 80 o 90 con una fase llamada "Codificación y Prueba de Unidad" (frente a "Codificación"). (Lo siento, no recuerdo dónde, así que no puedo proporcionar citas). Por lo tanto, las pruebas unitarias han existido y evolucionado durante bastante tiempo.

— GreenMatt

2

Creo que no, la facilidad de las pruebas unitarias es uno de los beneficios, pero es parte de una colección de beneficios cuando se usa MVC junto con las razones que enumera. Decir que hay una sola razón principal para usar MVC es un error. Parece que la compañía en cuestión elige MVC para facilitar las pruebas unitarias, por lo tanto, creen que es la razón principal. Personalmente, mis razones para usar MVC son su simplicidad en comparación con los formularios web, lo que facilita su diseño y mantenimiento, pero cada individuo / empresa tendrá sus propias razones para usar cualquier tecnología.

— Robert Anton Reese
fuente

0

En el mundo MVC de ASP.NET, se han incluido muchas mejoras en ASP.NET en el propio marco. El objetivo principal de este patrón de diseño es aislar la lógica empresarial de la interfaz de usuario para centrarse en una mejor capacidad de mantenimiento, una mejor capacidad de prueba y una estructura más limpia para la aplicación.

ASP.NET MVC tiene ciertas capacidades que lo convierten en la mejor opción para elegir si necesita uno o más de los siguientes:

• Un alto nivel de control sobre el HTML generado : a diferencia de los formularios web, las vistas en ASP.NET MVC procesan HTML exactamente como usted les indica. Recientemente, los formularios web se han mejorado en esta área, pero todavía no tienen el nivel de control que tiene MVC.

• Pruebas unitarias más sencillas : con ASP.NET MVC, es muy fácil seguir patrones de prueba como el desarrollo basado en pruebas (TDD). Debido al complejo ciclo de vida de eventos en Web Forms, además de un marco basado en control, TDD es mucho más fácil con MVC.

• Separación de preocupaciones : Esto se refiere a tener todos los aspectos del sistema claramente separados uno del otro. Debido al patrón que implementa, una aplicación MVC se divide en partes discretas y unidas libremente (modelo, vistas y controladores), lo que facilita su mantenimiento.

Algunos de los otros beneficios son:

• El patrón MVC en sí mismo facilita la gestión de la complejidad al separar claramente la funcionalidad de la aplicación en tres partes principales, el modelo, la vista y el controlador.

• Las aplicaciones web ASP.NET MVC no utilizan el estado de vista ni los formularios basados en el servidor. Esto hace que el marco MVC sea ideal para desarrolladores que desean un control total sobre el comportamiento de una aplicación. El estado de visualización puede ser muy grande, lo cual es un problema para dispositivos como teléfonos inteligentes que se ejecutan en redes lentas (la transmisión de toda esa información puede ser muy lenta). En una página de formularios web, solo puede tener uno por página. Esta es una restricción bastante importante. En MVC, no existe tal restricción, es decir, puede tener tantos elementos como desee.

• ASP.NET MVC proporciona un mejor soporte para el desarrollo basado en pruebas (TDD).

• ASP.NET MVC funciona bien para aplicaciones web compatibles con grandes equipos de desarrolladores y para diseñadores web que necesitan un alto grado de control sobre el HTML. Proceso de solicitud de ASP.NET MVC

— Arvind Kumar
fuente