silverlight - visual - ¿TDD se aplica bien al desarrollar una UI?
unit testing using dotnet test (10)
¿Cuáles son sus opiniones y experiencias con respecto al uso de TDD al desarrollar una interfaz de usuario?
Hace tiempo que medito sobre esta cuestión y no puedo tomar una decisión final. Estamos a punto de comenzar un proyecto de Silverlight, y analicé el Marco de prueba de la unidad de Microsoft Silverlight con TDD en mente, pero no estoy seguro de cómo aplicar el enfoque al desarrollo de la interfaz de usuario en general, ni a Silverlight en particular.
EDITAR: La pregunta es si es práctico usar TDD para el desarrollo de UI, no sobre cómo separar las preocupaciones.
El desarrollo basado en pruebas se presta más para desarrollar código que para desarrollar interfaces de usuario. Hay algunas maneras diferentes en que se realiza TDD, pero la forma preferida de TDD verdadero es escribir sus pruebas primero, luego escriba el código para pasar las pruebas. Esto se hace iterativamente durante el desarrollo.
Personalmente, no estoy seguro de cómo realizar TDD para UI; sin embargo, el equipo en el que participo realiza pruebas de simulación automatizadas de nuestras IU. Básicamente, tenemos un conjunto de simulaciones que se ejecutan cada hora en la compilación más reciente de la aplicación. Estas pruebas realizan acciones comunes y verifican que determinados elementos, frases, diálogos, etc. ocurran correctamente según, por ejemplo, un conjunto de casos de uso.
Por supuesto, esto tiene sus desventajas. La desventaja de esto es que las simulaciones están bloqueadas en el código que representa el caso. Deja poco espacio para la varianza y básicamente dice que espera que el usuario haga exactamente este comportamiento con respecto a esta característica.
Algunas pruebas son mejores que ninguna prueba, pero podría ser mejor.
Sí, puede usar TDD con gran efecto para la prueba GUI de aplicaciones web.
Al probar las GUI, normalmente utiliza datos auxiliares / falsos que le permiten probar todos los cambios de estado diferentes en su GUI. Debe separar su lógica comercial de su GUI, porque en este caso querrá burlarse de su lógica comercial.
Esto es realmente bueno para atrapar aquellas cosas que los probadores siempre olvidan al hacer clic; ellos también tienen ceguera en los exámenes
Tratar de probar la ubicación exacta de los componentes de la interfaz de usuario no tiene sentido. Primero porque el diseño es subjetivo y debe ser "probado" por los humanos. En segundo lugar, porque a medida que cambia la interfaz de usuario, estará constantemente reescribiendo sus pruebas.
Del mismo modo, no pruebes los componentes de la GUI por sí mismos, a menos que estés escribiendo nuevos componentes. Confíe en el marco para hacer su trabajo.
En su lugar, debe probar el comportamiento subyacente a esos componentes: los controladores y modelos que componen su aplicación. Usar TDD en este caso lo lleva a una separación de preocupaciones, de modo que su modelo es realmente un objeto de administración de datos y su controlador es realmente un objeto de comportamiento, y ninguno de ellos está estrechamente vinculado a la IU.
Las GUIs por su propia naturaleza son difíciles de probar, por lo que Brian Rasmussen sugiere mantener el código del cuadro de diálogo separado del código de la GUI.
Este es el patrón de cuadro de diálogo humilde .
Por ejemplo, puede tener un cuadro de diálogo donde se ingresan los detalles (por ejemplo, el número de tarjeta de crédito) y debe verificarlos. En este caso, pondría el código que verifica el número de la tarjeta de crédito con el algoritmo de Luhn en un objeto separado que usted probará. (El algoritmo en cuestión simplemente prueba si el número es plausible; está diseñado para verificar errores de transcripción).
No puedo hablar con Microsoft Silverlight, pero nunca utilizo TDD para ningún tipo de problema de diseño, simplemente no vale la pena el tiempo. Lo que funciona bien es el uso de pruebas unitarias para verificar cualquier tipo de cableado, validación y lógica de UI que hayas implementado. La mayoría de los sistemas le brindan acceso programático a las acciones que realiza el usuario, puede usarlas para afirmar que sus expectativas se cumplen correctamente. Por ejemplo, si llama al método click () en un botón, debe ejecutar el código que desee. Al seleccionar un elemento en una vista de lista, se cambia todo el contenido de los elementos de la interfaz de usuario a las propiedades de estos elementos ...
En función de su edición, aquí hay un poco más de detalles sobre cómo lo hacemos en mi equipo actual. Estoy haciendo Java con GWT, por lo que la aplicación de Silverlight podría estar un poco mal.
Requisito o error entra al desarrollador. Si hay un cambio de UI (L y F) hacemos una simulación rápida del cambio de UI y se lo enviamos al propietario del producto para su aprobación. Mientras esperamos eso, comenzamos el proceso de TDD.
Comenzamos al menos con una prueba web (usando Selenium para hacer clic en los usuarios en un navegador) o una prueba funcional "sin cabeza" usando Concordion, FiT o algo similar. Una vez hecho y fallado, tenemos una visión de alto nivel de dónde atacar los servicios subyacentes para que el sistema funcione correctamente.
El siguiente paso es excavar y escribir algunas pruebas de unidad y de integración defectuosas (creo que las pruebas unitarias son independientes, sin dependencias, sin datos, etc. Las pruebas de integración son pruebas completamente cableadas que leen / escriben en la base de datos, etc.)
Entonces, lo hago funcionar de abajo hacia arriba. Parece que su fondo TDD le permitirá extrapolar los beneficios aquí. Refactor en el camino también ...
Miro más a TDD desde la perspectiva de la interfaz de usuario a partir de los simples criterios de aceptación para que pase la interfaz de usuario. En algunos círculos, esto se cataloga como ATDD o desarrollo impulsado por prueba de aceptación.
La mayor sobre-ingeniería que he encontrado al usar TDD para UI es cuando me entusiasmé con el uso de pruebas automatizadas para evaluar problemas de apariencia y sensación. Mi consejo: ¡no! Concéntrese en probar el comportamiento: este clic produce estos eventos, estos datos están disponibles o se muestran (pero no cómo se muestran). Look and Feel es realmente el dominio de su equipo de pruebas independiente.
La clave es enfocar tu energía en actividades de "agregar valor alto". Las pruebas automáticas de estilo son más una deuda (manteniéndolas actualizadas) que un valor añadido.
Si separa la lógica del código GUI real, puede usar TDD fácilmente para construir la lógica y será mucho más fácil construir otra interfaz además de su lógica, si alguna vez lo necesita.
Creo que esta publicación de blog de Ayende Rahien responde muy bien mi pregunta utilizando un enfoque pragmático y sensato. Aquí hay algunas citas de la publicación:
La interfaz de usuario de prueba, por ejemplo, es un lugar común donde simplemente no vale la pena el tiempo y el esfuerzo.
...
La calidad del código, la flexibilidad y la capacidad de cambiar son otras cosas que a menudo se atribuyen a las pruebas. Ciertamente ayudan, pero de ninguna manera son la única (o incluso la mejor) manera de abordar eso.
Las pruebas solo se deben usar cuando agreguen valor al proyecto, sin convertirse en el foco principal. Finalmente, estoy bastante seguro de que el uso del desarrollo basado en pruebas para la interfaz de usuario puede convertirse rápidamente en la fuente de mucho trabajo que simplemente no vale la pena.
Tenga en cuenta que parece que la publicación trata principalmente de probar DESPUÉS de que se hayan construido cosas, no ANTES (como en TDD), pero creo que la siguiente regla de oro sigue siendo válida: las cosas más importantes merecen el mayor esfuerzo y las menos importantes merecen menos esfuerzo. . Tener una UI probada en una unidad a menudo no es TAN importante y, como escribe Ayende, el beneficio de usar TDD como modelo de desarrollo probablemente no sea tan bueno, especialmente cuando piensas que desarrollar una UI es normalmente un proceso descendente.
En mi lugar de trabajo utilizamos TDD y en realidad probamos unitariamente nuestro código UI (para una aplicación web) gracias al WicketTester de Apache Wicket pero no estamos probando que alguna etiqueta descriptiva esté antes de un campo de texto o algo así, sino que probamos esa jerarquía de los componentes es algo correcto ("la etiqueta está en el mismo subconjunto que el campo de texto ") y los componentes son lo que se supone que son (" esta etiqueta es realmente una etiqueta ").
Al igual que otros ya han dicho, le corresponde a la persona real determinar cómo se colocan esos componentes en la interfaz de usuario, no el programador, especialmente porque los programadores tienden a hacer herramientas de línea de comando todo en uno / oscuro en lugar de UI que son fácil de usar.