unit testing - que - ¿La mejor práctica para integrar TDD con el desarrollo de aplicaciones web?
tdd pdf (7)
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 dificultad de escribir la automatización de la interfaz de usuario a mitad del desarrollo.
¿Cómo integra usted o su organización las mejores prácticas de TDD con el desarrollo de aplicaciones web?
Esta es una buena pregunta, una que me suscribiré también :)
Todavía soy relativamente nuevo en el desarrollo web, y también estoy buscando un montón de código que no ha sido probado en gran medida.
Para mí, mantengo la UI lo más liviana posible (normalmente solo unas pocas 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? Quizás no, pero al menos todavía bastante automatizado y el código central (donde ocurre la mayor parte de la "magia") todavía tiene una cobertura bastante buena.
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 analizado FitNesse, Watin y Selenium como opciones para automatizar las pruebas de UI, pero aún no he podido utilizarlas en ningún proyecto, por lo que nos quedamos con 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!).
Se han intentado obtener la automatización de UI gratuita de Microsoft (incluida en .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 ( enlace ).
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 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.
Ivonna puede evaluar tus puntos de vista por unidad. Aún así, recomendaría mover la mayor parte del código a otras partes. Sin embargo, algunos códigos solo pertenecen allí, como referencias a controles o controladores de eventos de control.
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 conjunto de pruebas antes de escribir 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.
Intente 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íes en ti mismo . Supongamos que siempre cometerá errores y, por lo tanto, escribe pruebas para facilitar su vida, no más.
Si no te sientes bien con la redacción de exámenes, probablemente lo estés haciendo mal;)
Se podrán realizar pruebas unitarias si separa las capas de forma adecuada. Como Rob Cooper dio a entender, no coloque 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, a algunas personas les gusta el selenio . Otros se quejan de que es un dolor de establecer.
Una práctica común es mover todo el código que pueda fuera del código subyacente y dentro de un objeto que pueda 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 Web Forms que he visto.
Su código detrás, al seguir este patrón, hará dos cosas:
- Transfiera todas las acciones del usuario al presentador.
- Renderizar datos proporcionados por el presentador.
La prueba unitaria del presentador debe ser trivial.
Actualización: Rhino Igloo se puede encontrar aquí: https://svn.sourceforge.net/svnroot/rhino-tools/trunk/rhino-igloo/