Desarrollo controlado por prueba (TDD) para interfaz de usuario (UI) con pruebas funcionales

Question

Como sabemos, TDD significa "escribir primero la prueba y luego escribir el código". Y cuando se trata de pruebas unitarias, está bien, porque estás limitado dentro de la "unidad".

Sin embargo, cuando se trata de la interfaz de usuario, escribir pruebas funcionales de antemano tiene menos sentido (para mí). Esto se debe a que las pruebas funcionales tienen que verificar un conjunto de requisitos funcionales (posiblemente largos). Esto por lo general puede abarcar varias pantallas (páginas), condiciones previas como "conectado", "que recientemente ha insertado un registro", etc.

According to Wikipedia:

desarrollo basado en pruebas es difícil de usar en situaciones en plena se requieren pruebas funcionales para determinar el éxito o el fracaso. Ejemplos de esto son las interfaces de usuario, los programas que funcionan con bases de datos y algunos que dependen de configuraciones de red específicas.

(Por supuesto, Wikipedia no es una "autoridad", pero esto suena muy lógico.)

Por lo tanto, cualquier pensamiento, o mejor - experiencia, con el funcional pruebas primero para la interfaz de usuario, y luego código. ¿Funciona? Y es "dolor"?

Answer 1

Probar BDD, Behavior Driven Development. Promueve escribir historias de especificación que luego se ejecutan paso a paso estimulando la aplicación para que cambie su estado y verifique los resultados.

Uso los escenarios BDD para escribir el código UI. Las solicitudes comerciales se describen utilizando historias BDD y luego se escribe la funcionalidad para convertir las historias, es decir, las pruebas verdes.

Answer 2

Las pruebas de IU programáticas son una salvación cuando quieres estar seguro de que tu UI hace lo que se espera. Las pruebas de UI están más cerca de BDD (desarrollo impulsado por el comportamiento) que de TDD. ¡Pero la terminología es turbia y, como quiera que los llames, son útiles! Tengo bastante buena experiencia usando cucumber. Lo uso para probar aplicaciones flexibles, pero se usa principalmente para probar aplicaciones web. Haga clic en el enlace! El sitio tiene ejemplos realmente buenos de metodología.

Answer 3

Intente combinar BDD con TDD.

• BDD define escenarios como la interacción con la GUI (no implementado todavía)
• mientras que hay una "no implementado BDD-Step" (gris o rojo)
  • Convertir algunos no implementado BDD-Paso de la scenarion actual en la ejecución de código
  • implementar este paso utilizando TDD

Para más detalles ver MSDN-Article Behavior-Driven Development with SpecFlow and WatiN. Aunque el artículo trata sobre asp.net, la idea detrás es universal.

Answer 4

He hecho la aceptación TDD con una IU. Afirmaríamos que el encabezado y el pie de página comunes se usaron mediante xpath'ing para los ID apropiados. También usamos xpath para afirmar que los datos aparecían en la etiqueta correcta en relación con los identificadores que usamos para el diseño y la estructura básicos. También afirmaríamos que la página de salida es válida html 4.01 estricta.

Answer 5

ATDD es muy útil si tiene una buena comprensión de cómo se debe comportar la IU y también se asegura de que el costo de cambio en las pruebas funcionales que construye por adelantado es menor.

El mayor problema al hacer esto, por supuesto, es que la interfaz de usuario no está totalmente especificada. Por ejemplo, si está creando un producto y todavía está realizando iteraciones rápidas para obtener una IU que pasa por una prueba de usabilidad y los comentarios incorporados, no quiere el equipaje de arreglar sus pruebas funcionales con cada cambio pequeño. a la IU.

Dado que las pruebas funcionales generalmente son lentas, el ciclo de retroalimentación es alto y es muy doloroso mantenerlas verdes con los cambios en la IU.

Trabajo en un equipo de producto donde tomamos la misma decisión. Un colega mío ha resumido muy bien nuestro enfoque final here. (Descargo de responsabilidad: Por favor, ignore los detalles específicos de la herramienta allí.)

Answer 6

TDD para pruebas funcionales tiene sentido para mí. Escriba una prueba funcional, vea que falla, luego divida el problema en partes, escriba una prueba unitaria para cada parte, escriba el código para cada parte, vea pasar las pruebas unitarias y luego su prueba funcional pase.

Aquí es un flujo de trabajo sugerido en el libro Test-Driven Development with Python por Harry Percival (disponible en línea de forma gratuita):

P. S. Puede automatizar sus pruebas funcionales utilizando, p. Selenio. Puede agregarlos al ciclo de integración continua así como a las pruebas unitarias.

Answer 7

La clave para probar una IU es separate your concerns - el comportamiento de su IU es en realidad diferente al aspecto de su IU. Luchamos con esto mentalmente, así que como ejercicio, tome un juego como Tetris e imagínelo portándolo desde una plataforma (por ejemplo, PC) a otra (la web). La intuición es que todo es diferente, ¡tienes que reescribir todo! Pero en realidad todo esto es lo mismo:

• Las reglas del juego.
• La velocidad de los bloques cayendo.
• La lógica de las filas coincidentes
• qué bloque se elige
• Y más ...

se entiende la idea. Lo único que cambia es cómo se dibuja la pantalla. Así que separe la apariencia de su interfaz de usuario de cómo funciona. Esto es complicado, y generalmente no puede ser perfecto, pero está cerca. Mi recomendación es escribir la UI al final. Las pruebas proporcionarán los comentarios si su comportamiento está funcionando, y la pantalla dirá si se ve bien. Esta combinación proporciona los comentarios rápidos que estamos buscando de TDD sin una IU.