¿Cómo puede TDD para un error que solo se puede probar después de que se haya solucionado?

13

Aquí hay un ejemplo: Mi aplicación web contiene elementos que se pueden arrastrar. Al arrastrar un elemento, el navegador produce una "imagen fantasma". Quiero eliminar la "imagen fantasma" al arrastrar y escribo una prueba para este comportamiento.

Mi problema es que inicialmente no tengo idea de cómo solucionar este error y la única forma en que puedo escribir una prueba es después de haberla solucionado.

En una función simple como let sum = (a, b) => a - b , puedes escribir una prueba de por qué sum(1, 2) no es igual a 3 antes de escribir cualquier código.

En el caso que estoy describiendo, no puedo realizar la prueba porque no sé qué es la verificación (no sé cuál debería ser la afirmación).

Una solución al problema descrito es:

let dataTransfer = e.dataTransfer
let canvas = document.createElement('canvas');
canvas.style.opacity = '0';
canvas.style.position = 'absolute';
canvas.style.top = '-1000px';
dataTransfer.effectAllowed = 'none';

document.body.appendChild(canvas);
dataTransfer.setDragImage(canvas, 0, 0);

No podría haber sabido que esta era la solución. Ni siquiera podría haber escrito la prueba después de encontrar la solución en línea, porque la única forma de saber si realmente funcionó, fue agregar este código en mi código base y verificar con el navegador si tuvo el efecto deseado. La prueba tuvo que escribirse después del código, que va en contra de TDD.

¿Cuál sería el enfoque TDD para este problema? ¿Escribir la prueba antes del código es obligatorio u opcional?

    
pregunta maximedupre 23.05.2018 - 23:01

4 respuestas

24

Cuando lo entendí correctamente, ni siquiera puede escribir una prueba automatizada confiable para su ejemplo de "imagen fantasma" después que encontró una solución, ya que la única forma de verificar el comportamiento correcto es mirar La pantalla y comprobar si ya no hay imagen fantasma. Eso me da la impresión de que su titular original hizo la pregunta equivocada. La verdadera pregunta debería ser

  • ¿Cómo probar automáticamente un determinado comportamiento de una interfaz gráfica de usuario?

Y la respuesta es: para varios tipos de problemas de IU, no lo haces . Claro, uno puede intentar automatizar el hecho de que la interfaz de usuario muestre el problema de alguna manera e intentar implementar algo como una comparación de captura de pantalla, pero a menudo es propenso a errores, es frágil y no es rentable.

Especialmente el diseño de la interfaz de usuario de "prueba de manejo" o las mejoras de la interfaz de usuario por pruebas automatizadas escritas con anticipación son literalmente imposibles. Usted "conduce" el diseño de la interfaz de usuario haciendo una mejora, muestra el resultado a un ser humano (usted mismo, algunos evaluadores o un usuario) y solicita comentarios.

Entonces, acepte el hecho de que TDD no es una bala de plata, y para algunos tipos de problemas, las pruebas manuales tienen más sentido que las pruebas automatizadas. Si tiene un proceso de prueba sistemático, tal vez con algunos evaluadores dedicados, lo mejor que puede hacer es agregar el caso a su plan de prueba.

    
respondido por el Doc Brown 23.05.2018 - 23:25
3
  

¿Cuál sería el enfoque TDD para este problema? ¿Escribir la prueba antes del código es obligatorio u opcional?

Una forma es aplicar un análogo de una solución de picos .

James Shore lo describió de esta manera:

  

Realizamos experimentos pequeños y aislados cuando necesitamos más información.

La idea básica es que sueltes las herramientas de diseño mientras descubres lo que está sucediendo. Una vez que se haya orientado, retomará las herramientas de diseño.

El truco: devuelve el conocimiento de su investigación a su base de código de producción, pero no trae el código . En su lugar, lo recrean mientras usas tus técnicas de diseño disciplinado.

Caballos para cursos.

EDITAR:

  

¿Cómo se puede automatizar una prueba si el defecto solo puede ser visto por un ojo humano?

Me gustaría sugerir una ortografía ligeramente diferente: "¿Cómo se puede automatizar una prueba si la automatización de la prueba no es rentable?"

La respuesta, por supuesto, es "no". En su lugar, esfuércese por separar su implementación en dos partes: una parte grande donde las pruebas son rentables y una parte más pequeña que es demasiado simple de romper.

  

Hay dos formas de construir un diseño de software: una es hacer que sea tan simple que obviamente no hay deficiencias - C.A.R. Hoare

Entonces, cuando trabajemos con un código de terceros, tendremos un código muy delgado que actúa como un proxy para la biblioteca de terceros. En la prueba, reemplazamos esa cáscara con una "prueba doble", que verifica el protocolo , sin preocuparnos de que produzca los efectos deseados.

Para la prueba de la integración de nuestros códigos con el código de terceros real, confiamos en otras técnicas (verificación visual, llamadas de soporte técnico, optimismo ...)

Puede ser útil mantener algunos artefactos de demostración alrededor, para que pueda verificar que sus suposiciones aún se mantienen cuando actualiza la biblioteca de terceros.

    
respondido por el VoiceOfUnreason 23.05.2018 - 23:28
0

Solo desde una perspectiva diferente, las pruebas en torno a la interfaz de usuario / GUI se pueden hacer un poco mejor con respecto a las pruebas de aceptación (pruebas centradas en el flujo de trabajo de funciones / negocios).

Para la web, creo que los frameworks como Selenium webdriver tienen el potencial de acercarse a la prueba correcta, pero la sobrecarga para comenzar puede ser un poco grande, y es un cambio en el flujo observado con TDD con respecto a solo pruebas unitarias.

La parte que específicamente ayudaría con su situación es algo que se llama Page Object Model ( enlace ). Esto logra una asignación explícita de la GUI en tiempo de ejecución a algún código, ya sea al nombrar los métodos / eventos / miembros de la clase.

Los principales argumentos en contra de esto serían los gastos generales, y que estos gastos generales generalmente podrían verse al final del ciclo de desarrollo. La sobrecarga es que las pruebas requieren algún envoltorio que parezca crear un trabajo duplicado.

Avanzando, dependería del costo / beneficio del equipo y la empresa, por lo que podría ser un tema beneficioso para analizar para determinar las expectativas y las opiniones.

    
respondido por el eparham7861 24.05.2018 - 16:26
0

¿Cómo se ve una imagen fantasma? Si creó una interfaz de usuario ficticia de un color conocido, ¿dónde colocó su componente que se puede arrastrar? ¿Habría un color específico presente si hubiera una imagen fantasma?

Luego, la prueba podría probar la ausencia del color de la imagen fantasma.

Tal prueba sería razonable, duradera y factible.

    
respondido por el Esben Skov Pedersen 24.05.2018 - 08:51

Lea otras preguntas en las etiquetas