¿La mejor práctica para integrar TDD con el desarrollo de aplicaciones web?

Question

Las pruebas unitarias y las aplicaciones web ASP.NET son un punto ambiguo en mi grupo. La mayoría de las veces, las buenas prácticas de prueba caen por las grietas y las aplicaciones web terminan funcionando durante varios años sin pruebas.

La causa de este punto de dolor generalmente gira en torno a la molestia de escribir la automatización de la interfaz de usuario a mitad del desarrollo.

¿Cómo integran usted o su organización las mejores prácticas de TDD con el desarrollo de aplicaciones web?

Answer 1

Prueba de la unidad será alcanzable si separar las capas apropiadamente . Como implicó Rob Cooper, no ponga ninguna lógica en su WebForm aparte de la lógica para administrar su presentación. Todas las otras capas lógicas y de persistencia deben mantenerse en clases separadas y luego puede probarlas individualmente.

Para probar la GUI algunas personas como selenium. Otros se quejan de que es un dolor de establecer.

Answer 2

Extiendo la capa de la aplicación y al menos la prueba unitaria del presentador/controlador (lo que sea su preferencia, mvc/mvp) a la capa de datos. De esa manera tengo una buena cobertura de prueba sobre la mayor parte del código que se escribe.

He examinado FitNesse, Watin y Selenium como opciones para automatizar las pruebas de UI, pero aún no he tenido tiempo de utilizarlas en ningún proyecto, por lo que seguimos con las pruebas en humanos. FitNesse era a quien me estaba inclinando, pero no podía presentarlo así como presentar TDD (¿eso me hace mal? ¡Espero que no!).

Answer 3

Esta es una buena pregunta, una que se suscriban también :)

Soy relativamente nuevo en web dev, y yo también estoy buscando a una gran cantidad de código que está puesto a prueba.

Para mí, guardo la IU lo más ligera posible (normalmente solo unas líneas de código) y pruebo la mierda de todo lo demás. Al menos puedo confiar en que todo lo que hace que la interfaz de usuario sea lo más correcto posible.

¿Es perfecto? Tal vez no, pero al menos es como sigue siendo bastante altamente automatizado y el código del núcleo (donde la mayoría de la "magia" que ocurre) todavía tiene bastante buena cobertura ..

Answer 4

Una práctica común es mover todo el código que pueda fuera del código subyacente y dentro de un objeto que puede probar de forma aislada. Dicho código generalmente seguirá los patrones de diseño MVP o MVC. Si busca en "Rhino Igloo", probablemente encontrará el enlace a su repositorio de Subversion. Vale la pena estudiar ese código, ya que demuestra una de las mejores implementaciones de MVP en formularios web que he visto.

Su código subyacente hará, cuando se sigue este patrón, hacer dos cosas:

1. Tránsito todas las acciones del usuario a la presentadora.
2. Renderizar datos proporcionados por el presentador.

La prueba de la unidad del presentador debe ser trivial.

Actualización: Rhino Igloo se puede encontrar aquí: https://svn.sourceforge.net/svnroot/rhino-tools/trunk/rhino-igloo/ intentos

Answer 5

Se han producido en conseguir UI Automation gratuito de Microsoft (incluido en el .NET Framework 3.0) para trabajar con aplicaciones web (ASP.NET). Una compañía alemana llamada Artiso ha escrito una entrada de blog que explica cómo lograr eso (link).

Sin embargo, su blogpost también vincula un webcasts de MSDN que explica el Marco de automatización de UI con winforms y, después de echar un vistazo a esto, noté que necesita el AutomationId para obtener una referencia a los controles respetuosos. Sin embargo, en aplicaciones web, los controles no tienen un AutomationId.

Le pregunté a Thomas Schissler (Artiso) sobre esto y me explicó que esto era una gran desventaja en InternetExplorer. Hizo referencia a una tecnología más antigua de Microsoft (MSAA) y esperaba que IE8 lo hiciera mejor.

Sin embargo, también le estaba dando una oportunidad a Watin y parece funcionar bastante bien. Incluso me gustó Wax, que permite implementar testcases simples a través de hojas de cálculo de Microsoft Excel.

Answer 6

Ivonna puede evaluar sus puntos de vista. Aún así, recomendaría mover la mayor parte del código a otras partes. Sin embargo, algunos códigos solo pertenecen a, como referencias a controles o controladores de eventos de control.

Answer 7

En general, evitaría las pruebas que implican confiar en los elementos de la interfaz de usuario. Estoy a favor de las pruebas de integración, que prueban todo, desde la capa de la base de datos hasta la capa de visualización (pero no el diseño real).

Intente iniciar un banco de pruebas antes de escribiendo una línea de código real en un nuevo proyecto, ya que es más difícil escribir pruebas más tarde.

Elija cuidadosamente lo que prueba, no escriba pruebas sin pensar para todo. A veces es una tarea aburrida, así que no lo hagas más difícil. Si escribe demasiadas pruebas, corre el riesgo de abandonar esa tarea bajo el peso del mantenimiento que consume mucho tiempo.

Intenta agrupar la mayor funcionalidad posible en una sola prueba. De esa forma, si algo sale mal, los errores se propagarán de todos modos. Por ejemplo, si tiene una clase generadora de digestión, pruebe la salida real, no todas las funciones auxiliares.

No confíe en usted mismo. Supongamos que siempre cometerá errores y, por lo tanto, escribe pruebas para facilitar su vida, no más.

Si no se siente bien acerca de pruebas de escritura, es probable que esté haciendo mal;)