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?
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.
fuente
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.
fuente
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.fuente