Tratando con las pruebas de Selenium que fallan ocasionalmente durante la implementación automatizada

Question

Tenemos una aplicación web C#/ASP .NET que es desarrollada e implementada por el servidor de compilación (Jenkins). Uno de los pasos previos a la implementación automatizada es garantizar que todas las pruebas automatizadas pasen, incluidas las pruebas funcionales que tenemos utilizando Selenium 2 WebDriver y NUnit.

El problema: a veces estas pruebas fallan aleatoriamente. Tendrán éxito para 100 construcciones y luego una falla. Fallan por varias razones: un evento .Click() se ignora, no se puede encontrar el elemento, IE tiene un mal día, etc. Tenemos una aplicación web pesada AJAX, por lo que dependemos en gran medida de WebDriverWaits, pero siempre tomamos esto en cuenta mientras escribo las pruebas, y como dije, las pruebas pasan la mayor parte del tiempo.

¿Cuáles son algunas maneras de evitar o solucionar este problema? Una pareja que vino a la mente:

• aceptar un cierto número de fallos (parece una mala idea)
• fallos de las pruebas Volver a ejecutar?

Answer 1

No me gusta ninguna de las sugerencias que mencionas, pero admito haberlas usado ocasionalmente. Lo mejor que puede hacer es asegurarse de que cuando haya un error aparentemente "aleatorio" al hacer todo lo posible para obtener todos los datos sobre por qué falló realmente. ¿Fue un problema ambiental? ¿Algún otro proceso en la máquina interfiere con las pruebas? ¿Fue un problema de temporización que solo aparece cuando el sitio se carga de manera insoportablemente lenta o muy rápido?

Una cosa que puedes probar es probar tus pruebas automáticas. Ejecute cada uno más de 100 veces en la misma construcción y en el mismo entorno (para que pueda descartarlos como posibles puntos de falla) y encuentre los que fallan ocasionalmente. Vea si fallan en el mismo lugar o en diferentes lugares. Generalmente, cuando realizas este ejercicio, encontrarás algunas pruebas que realmente son un poco escamosas y puedes eliminarlas de la rutina diaria hasta que se solucionen. Incluso podría incluir un remojo como criterio de registro para cualquier caso de prueba automatizada.

Otra cosa útil que he encontrado que me ayudó a llegar al fondo de algunas de las fallas aparentemente aleatorias fue tomar capturas de pantalla en el fracaso. A menudo puede ver que aparecieron otras ventanas o cuadros de diálogo que hacen que los navegadores no puedan estar al frente, etc.

Answer 2

De los dos, preferiría volver a ejecutar fallas de prueba, o más bien, en una falla de prueba, vuelva a intentar las pruebas.

Si acepta una cierta cantidad de fallas de prueba, entonces tiene problemas con las pruebas que pueden fallar. Tendría que tener dos conjuntos de pruebas, algunas que pueden fallar, otras que no.

Para volver a ejecutar, no soy un experto en las pruebas con NUnit, pero podría tener los propios exámenes para gestionar el reintento. En JUnit, puede introducir una regla para que, si falla una prueba, vuelva a intentar un máximo de 3 veces. Esto probablemente evitaría la mayoría de los problemas que tienes. No sé cómo hacer esto en NUnit, pero vea my answer a How to Re-run failed JUnit tests immediately?. Esto te dará la idea general.