¿Los controladores en aplicaciones web MVC deben ser verificados por la unidad?

Question

Me parece que los desarrolladores web de diferentes lenguajes de programación a menudo comparten opiniones diferentes al respecto. Por ejemplo, los desarrolladores web de Ruby (con Rails siendo el marco dominante) parecen pensar en los controladores como código de pegamento, que debería tener pruebas funcionales, pero no pruebas unitarias. Una actitud similar domina en el mundo de PHP, sin embargo, ha habido alguna iniciativa (por ejemplo, Symfony2).

Sin embargo, también parece que, por ejemplo, algunos desarrolladores de ASP.NET MVC realmente want their controllersto be unit-testable.

Lo que me gustaría saber es si realmente funciona en el desarrollo web. ¿Los controladores merecen pruebas unitarias? ¿Diseñarlos para que sean susceptibles de prueba por la unidad disminuyen notablemente la velocidad de desarrollo en aplicaciones no triviales? Además, ¿algún framework web intentó forzar la capacidad de prueba de la unidad del controlador? Las experiencias personales son bienvenidas.

Answer 1

Todo vale la pena probarlo. En este caso, depende de qué parte de la lógica se realiza en los controladores ... En un proyecto pequeño, no puede tener una lógica externa conectada y es posible que desee realizar algunas de las operaciones de la base de datos en su controlador (como en muchos ejemplos de Microsoft) . En soluciones más grandes, puede que no sea necesario probar el controlador en la medida en que su trabajo es invocar métodos de lógica de negocios especificados ... No se trata de si los controladores valen la pena probarse en una unidad, se trata de si el código que contienen es ...

Answer 2

Respuesta corta: "Sí", respuesta larga: "No" con "Sí".

En estos días tiendo a pasarme por alto las pruebas unitarias a nivel de controlador a favor de una sólida cobertura de pruebas de unidad de modelos y objetos comerciales y la cobertura de prueba funcional con Cucumber. La suposición aquí es que los controladores son objetos de enrutamiento de datos muy livianos en modelos subyacentes que encapsulan la gran mayoría de la lógica comercial.

Sin embargo, todavía tiendo a tener una cobertura muy ligera de parte del flujo de control en el nivel del controlador. Simplemente tiende a ser más una verificación de cordura.

Uno de los problemas con las pruebas a nivel de controlador es que a menudo tiene que burlarse o generar una gran cantidad de modelos y objetos para realizar pruebas con eficacia. Dado esto, me parece más valioso llevar estas pruebas a las capas funcionales donde el estilo de prueba te permite expresar estas dependencias de manera más eficiente (ya sea siguiendo explícitamente los pasos necesarios para generarlas a través de tu aplicación o mediante un sistema como Reglas declarativas del pepino).

Answer 3

Una de las mejores características del patrón MVC es que las vistas pueden probar los controladores de forma aislada del resultado HTML. Las páginas que mezclan la lógica con la salida HTML son difíciles de probar, y este es uno de los problemas resueltos por MVC: hace que tu controlador tenga que ver con la lógica y puedes probarlo sin analizar HTML en absoluto.

Idealmente, su controlador obtendrá datos de clases de acceso a datos separadas, que puede anular para sus pruebas, por lo que solo está probando la lógica. Básicamente, usted aisla su controlador de la base de datos de la misma manera que MVC lo aísla de la vista; entonces las pruebas son fáciles porque tampoco necesita una base de datos con datos de prueba.