¿Cómo puede escribir pruebas para el selenio (o similar) que no fallan debido a cambios menores o cosméticos?

Pasé la última semana más o menos aprendiendo selenio y creando una serie de pruebas web para un sitio web que estamos a punto de lanzar. ha sido genial aprender, y he aprendido algunas técnicas de ubicación de xpath y css.

Sin embargo, el problema para mí es ver pequeños cambios que rompen las pruebas: cualquier cambio en un div, un id o algún número de autoide que ayude a identificar widgets rompe cualquier número de pruebas, simplemente parece ser muy frágil.

Entonces, ¿ha escrito pruebas de selenio (u otras pruebas similares) y cómo se enfrenta a la naturaleza frágil de las pruebas (o cómo evita que sean frágiles) y para qué tipo de pruebas utiliza selenio?

testing selenium

— Sam J
fuente

Si pequeños cambios están rompiendo las pruebas, entonces las pruebas no se ejecutan después de que se realizan los cambios, que es el punto central de las pruebas. Además, parece que falta la conciencia del desarrollador sobre la (existencia de) las pruebas.

— talonx

@talonx: no es suficiente solo ejecutar este tipo de prueba, si un pequeño cambio resulta en un gran cambio en la suite, entonces será problemático independientemente de si son ejecutados por el desarrollador, el ci box o los probadores

— FinnNk

@FinnNK: De acuerdo, los pequeños cambios no deberían dar lugar a grandes cambios. Eso significa que los casos de prueba fueron escritos por alguien que no está en contacto con los desarrolladores que realizan los cambios, huele a una brecha de comunicación.

— talonx

@talonx: las pruebas de IU son inherentemente frágiles y su ejecución lleva mucho más tiempo que las pruebas unitarias. Son un desafío especial, por lo que no sacaría conclusiones acerca de los desarrolladores de la organización de @ Sam.

— azheglov

He cambiado el título, espero que sea un poco más representativo de la pregunta y un poco menos negativo.

— Jon Hopkins el

Respuestas:

El propósito de Selenium es crear pruebas de integración basadas en UI .

Las pruebas de integración verifican que todos los componentes de su sistema funcionan correctamente cuando se implementan juntos. Pruebas de integración no son una estrategia de prueba suficiente y complementan otras estrategias de ensayo que tienen un enfoque diferente, por ejemplo, pruebas unitarias y pruebas de aceptación .

Las pruebas basadas en la interfaz de usuario son inherentemente frágiles, aunque Selenium y Watir son un paso adelante desde los primeros días de las herramientas de grabación y reproducción . Hay varias formas de abordar este problema: aquí hay una recopilación de consejos de algunos expertos de clase mundial:

No intente obtener toda su cobertura de prueba de este tipo de pruebas . Robert C. Martin argumenta que la cobertura de su código mediante pruebas de integración debería ser aproximadamente del 20% . Simplemente no es práctico probar todas las rutas de ejecución cuando la entrada está a varias capas de aplicación.

Obtenga la mayor parte de la cobertura de las pruebas de unidad y de aceptación . Busque enlaces a los artículos de Gojko Adzic en la respuesta de FinnNk . Adzic discutió repetidamente sobre probar la lógica empresarial a través de pruebas de aceptación y omitiendo la interfaz de usuario.

Pero aún es necesario escribir cierta cantidad de pruebas basadas en la interfaz de usuario . Aquí es donde necesita algunos consejos prácticos además de "no pruebe su lógica empresarial a través de la interfaz de usuario". Recomendaría el blog de Patrick Wilson-Welsh como punto de partida.

— azheglov
fuente

El enlace para patrickwilsonwelsh.com no funciona más, y otro recurso para eso ... !!

— MarmiK

Lo más importante al crear pruebas como esta una vez que pasa un número trivial es la idea del cambio simétrico: un pequeño cambio en el código debería dar como resultado un pequeño cambio en el conjunto de pruebas.

Por ejemplo, supongamos que recopila el nombre de alguien con dos cuadros de texto en 100 pruebas. Si escribe esas pruebas ingenuamente (o tal vez está utilizando grabación de reproducción), entonces tendrá que cambiar 100 pruebas. Si, en cambio, abstrae un paso de 'ingresar nombre' y lo usa en sus pruebas en lugar de usar directamente selenio, entonces solo tiene 1 lugar para realizar el cambio. Dependerá de su contexto cuántas capas de abstracción use, pero usar la abstracción contribuirá en gran medida a que sus pruebas sean mantenibles.

Una segunda cosa importante es asegurarse de que sus selectores se basen en lo que es más importante y menos probable que cambie. Algunas veces esto será una identificación o una clase o podría ser el texto dentro o alrededor de un elemento. Siempre prefiera el selector más simple (p. Ej., Una identificación), pero a veces para lograrlo tendrá que usar algo como xpath.

Gojko Adzic tiene muchos buenos consejos en su blog cuando se trata de este tipo de pruebas: echa un vistazo a su Sine of Death y cómo evitarlo en particular.

— FinnNk
fuente

buenos consejos FinnNk: he extraído métodos comunes (iniciar sesión, buscar widgets de la barra lateral, etc.), por lo que el daño se reduce cuando las pruebas cambian. Desafortunadamente, estamos utilizando un sistema de propiedad que crea algunos de los widgets y crea identificadores para los widgets en función de su posición en el dom, por lo que cada vez que se mueve algo, se rompen las pruebas.

— Sam J

Por lo general, puede encontrar alguna forma de identificar un elemento, tal vez algún texto que contenga ese elemento, o tal vez siempre tenga la misma posición relativa con respecto a otra cosa. Finalmente, como último recurso, también puede definir estrategias de localización personalizadas para ubicar elementos usando selenio que le brinda control total (por ejemplo, si está buscando elementos con el nombre base del nombre y algunas cosas arbitrarias agregadas al final, como en su caso o en formularios web asp.net).

— FinnNk

Las pruebas aseguran que el código se comporte como se esperaba. Si sus pruebas se rompen de manera regular, entonces las pruebas no prueban lo correcto o los desarrolladores no se preocupan por las pruebas.

Personalmente, creo que si la presencia de una <div>etiqueta rompe una prueba, entonces la prueba depende innecesariamente estrictamente de las etiquetas circundantes, y se debe adoptar un enfoque más indulgente.