¿La TDD se aplica bien al desarrollar una IU?

Question

¿Cuáles son sus opiniones y experiencias con respecto al uso de TDD al desarrollar una interfaz de usuario?

He estado reflexionando sobre esta pregunta desde hace algún tiempo y simplemente no puedo tomar una decisión final. Estamos a punto de comenzar un proyecto de Silverlight y revisé el Microsoft Silverlight Unit Test Framework con TDD en mente, pero no estoy seguro de cómo aplicar el enfoque al desarrollo de la interfaz de usuario en general, o a Silverlight en particular.

EDIT: La pregunta se refiere a si es algo práctico utilizar TDD para IU-desarrollo, no se trata de cómo hacer la separación de preocupaciones.

Answer 1

Intentar 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.

De manera similar, no pruebe los componentes de la GUI, a menos que esté 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.

Answer 2

Si separa la lógica del código GUI real, puede usar TDD 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.

Answer 3

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 el TDD para las IU; 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 con respecto a esta característica.

Algunas pruebas son mejores que ninguna prueba, pero podría ser mejor.

Answer 4

Sí, puede usar TDD con gran efecto para la prueba GUI de aplicaciones web.

Cuando se prueban GUI, normalmente se utilizan datos auxiliares/falsos que le permiten probar todos los cambios de estado diferentes en su interfaz gráfica de usuario. 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

Answer 5

Miro a TDD desde una perspectiva de interfaz de usuario más desde el criterio de aceptación simple para que pase la IU.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 en el uso de TDD para UI es cuando me emocioné mucho con el uso de pruebas automatizadas para probar problemas de apariencia. 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 centrar su energía en actividades de "alto valor añadido". Las pruebas automáticas de estilo son más una deuda (manteniéndolas actualizadas) que un valor añadido.

Answer 6

Según 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 al desarrollador. Si hay un cambio de UI (L & 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.

Empezamos con al menos uno de o bien una prueba Web (usando selenio para conducir usuario hace clic en un navegador), o una prueba de funcionamiento "sin cabeza" usando Concordion, en forma o algo por el estilo. 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 desenterrar 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.)

Luego, hago que funcione de abajo hacia arriba. Parece que su fondo TDD le permitirá extrapolar los beneficios aquí. Refactor en el camino hacia arriba también ...

Answer 7

No puedo hablar con Microsoft Silverlight, pero nunca uso 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. P.ej. llamar al método click() en un botón debería ejecutar el código que pretendía. Seleccionar un elemento en una vista de lista cambia todo el contenido de los elementos de la interfaz de usuario a las propiedades de este elemento ...

Answer 8

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 GUI .

Este es el Humble Dialog Box Pattern.

Por ejemplo, es posible que tenga un cuadro de diálogo donde se ingresan los detalles (por ejemplo, número de tarjeta de crédito) y debe verificarlos. En este caso, debe colocar el código que verifica el número de la tarjeta de crédito con el Luhn algorithm en un objeto separado que pruebe. (El algoritmo en cuestión simplemente prueba si el número es plausible; está diseñado para verificar los errores de transcripción.)

Answer 9

Creo que this blog post de Ayende Rahien responde mi pregunta muy bien utilizando un enfoque pragmático y sensato. Aquí hay algunas citas del mensaje:

Pruebas de interfaz de usuario, por ejemplo, es un lugar común donde simplemente no vale la pena el tiempo y esfuerzo .

...

La calidad del código, la flexibilidad y la capacidad de cambio son otras cosas que a menudo se atribuyen a las pruebas. Ciertamente ayudan, pero son por no significa que el único (o incluso el mejor) manera de acercarse a eso.

Las pruebas solo se deben utilizar cuando agregan valor al proyecto, sin convertirse en el foco principal. Finalmente, estoy bastante seguro de que usar el desarrollo basado en pruebas para la IU puede convertirse rápidamente en la fuente de mucho trabajo que simplemente no lo vale.

Tenga en cuenta que parece que la publicación trata principalmente de probar DESPUÉS de que las cosas se hayan construido, no ANTES (como en TDD), pero creo que la siguiente regla de oro aún se aplica: Las cosas más importantes merecen el mayor esfuerzo y menos las cosas importantes merecen menos esfuerzo. Tener una UI probada en una unidad a menudo no es TAN importante y, como escribe Ayende, la ventaja de utilizar TDD como modelo de desarrollo probablemente no sea tan buena, especialmente cuando piensas que desarrollar una UI es normalmente un proceso descendente.

Answer 10

En mi lugar de trabajo utilizamos TDD y realizamos pruebas unitarias de nuestro código de UI (para una aplicación web) gracias al Apache WicketWicketTester pero no probamos que alguna etiqueta descriptiva esté delante de un campo de texto o algo así, sino que pruebe que la jerarquía de los componentes es algo correcta ("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 comandos todo en uno/oscuro de UI que son fáciles de usar.