Cucumber-js: implementar --reintentar

@ericyliu Viene en pepino 3. Sin embargo, no estoy seguro de por qué Pepino 2 todavía está en RC ... ha estado disponible durante 2 años

@charlierudolph o cualquiera, si tuvieras alguna sugerencia, estaría feliz de tomar esto y probarlo.

Mi enfoque presuntivo sería que al final de un escenario en ejecución podemos saber si falló o no y volver a ejecutarlo (manteniendo algún estado para el recuento de reintentos). ¿Dónde puedo engancharme a esto?

Además de esto, esperaría que al final de todo el proceso pueda acceder a una lista de todos los escenarios, la cantidad de veces que lo intentaron y sus estados finales, por lo que esto puede ser a) registrado yb) volcado al disco si lo desea .

Cerrando ya que personalmente no quiero implementar esto porque no estoy de acuerdo. No me gusta proporcionar una función que pueda usarse para hacer frente a una prueba de parpadeo en lugar de solucionar la causa del parpadeo.

👏👏👏

@charlierudolph a veces es imposible lidiar con pruebas de parpadeo. Por ejemplo, en nuestro entorno tenemos 23 servicios diferentes a los que llega nuestra aplicación, y como no somos propietarios de esos servicios, cualquiera de ellos puede estar inactivo en cualquier momento. el indicador --retry nos permite volver a ejecutar la prueba para que una interrupción temporal del servicio (cuando reinician el servicio) no haga que nuestra suite de pruebas falle.

Con respecto al desacuerdo personal con esta función (este argumento puede ser tan infructuoso como las pestañas frente a los espacios en el mundo de la ingeniería), si Cucumber como una especificación de herramientas está implementando esto, también deberíamos admitirlo en la versión JS de esta herramienta.

También se encuentra en el mundo real, con amplios conjuntos de pruebas y aplicaciones complejas imposibles de defender al 100% contra las fallas y, por lo tanto, se vuelve increíblemente costoso. Absolutamente, puede tener un viaje de ingeniería para mejorarlo, pero dudo que haya muchas empresas con el lujo de recursos para respaldar tal esfuerzo con un ROI decente.

En el mundo real, poder volver a intentar las pruebas fallidas con la adición de un buen seguimiento para identificar las fallas para la acción proactiva es muy valioso.

Agradecería que reconsideramos la decisión de cerrar este problema y, como se indicó anteriormente, estoy más que feliz de trabajar en esto con alguna orientación.

Para agregar a esto cucumber-js already tiene la funcionalidad rerun que es básicamente un reintento pero menos eficiente, ya que debe ejecutarse como un proceso separado (esto proporciona que lo entienda correctamente). Reintentar es una solución mucho mejor.

cc @charlierudolph

También se encuentra en el mundo real, con amplios conjuntos de pruebas y aplicaciones complejas imposibles de defender al 100% contra las fallas y, por lo tanto, se vuelve increíblemente costoso.

Odio absolutamente las pruebas de escamas. En mis proyectos actuales, estoy tratando de alejarme de ejecutar cualquier prueba de escamas en CI y guardarlas para ejecuciones manuales donde, si algo falla debido a fallas, puede volver a ejecutarlo o verificarlo manualmente. Esto depende de encontrar la fuente de descamación y de limitar la cantidad de pruebas que deben tratar con ella.

Para agregar a esto, cucumber-js ya tiene una funcionalidad de repetición que es básicamente un reintento pero menos eficiente, ya que debe ejecutarse como un proceso separado (esto proporciona que lo entienda correctamente). Reintentar es una solución mucho mejor

Rerun se creó para que pueda concentrarse fácilmente en las pruebas que deben solucionarse. Sí, puede usarlo para reintentar solo los escenarios fallidos.

Estoy 100% de acuerdo con que las pruebas inofensivas son algo que se debe evitar. Habiendo dicho eso, la escasez de una prueba es a menudo algo que no está bajo el control de un equipo. Esta es mi situación;

Estoy usando Cucumber, Nightwatch, Selenium y Browserstack para ejecutar pruebas de un extremo a otro en una aplicación web. A menudo, un escenario fallará debido a la escasez inherente de Selenium, Browserstack o el navegador en el que estoy probando. Las interacciones que involucran movimientos del mouse son notorias por esto. Es raro para mí poder recorrer todos mis escenarios sin que al menos un puñado sea inestable.

No puedo hacer que Selenium, Browserstack o los navegadores sean menos inestables, esa es solo la naturaleza de las herramientas con las que tengo que trabajar. La solución que necesito es poder volver a intentar mis escenarios un par de veces si fallan.

Creo que deberíamos reconsiderar esto. Pepino-Ruby lo tiene ahora.

Acordado. Aquí está el código para la implementación de Ruby. Podría ser útil para una implementación JS. https://github.com/cucumber/cucumber-ruby/pull/920/files

Hola a todos, ¿la función 'reintentar' ahora está disponible en Cucumber-JS? Por mucho que esté de acuerdo en que las pruebas inestables deben arreglarse, la experiencia muestra que no siempre es posible cuando se trabaja en proyectos grandes con muchas dependencias externas involucradas.
Al final del día, si un caso de prueba tan inestable no pudiera ser cubierto por la automatización debido a la lógica de un nuevo juicio faltante, entonces tendría que probarse manualmente de todos modos.
Creo que el uso de la lógica de reintento debe dejarse como una opción para el usuario de Cucumber.
Soy consciente de la función 'volver a ejecutar', pero usarla agrega complejidad adicional, ya que las pruebas deben volver a ejecutarse por separado en el lado opuesto para que el corredor Cucumber lo haga de manera transparente por usted.

Hola @charlierudolph y @aslakhellesoy. ¿Algún progreso con esta función?

Nadie está trabajando en eso que yo sepa. Sin embargo, si alguien proporciona una solicitud de extracción, consideraría agregarla.

Hola @aslakhellesoy gracias por responder tan rápido. Esto es algo que realmente necesitamos en este momento, ya que uno de los dispositivos que necesitamos automatizar es un poco inestable y, en tal caso, no hay alternativas realmente prácticas para volver a ejecutar un escenario fallido.
Mi idea es usar una etiqueta por escenario para especificar el recuento de reintentos, pero al menos como una implementación inicial que podría ser solo un parámetro de línea de comando.
Intentaré echarle un vistazo al código en los próximos días.

¡Eso seria genial! Intente que se comporte de la misma manera que en Cucumber-Ruby. Si difiere de eso, es posible que no lo fusionemos, ya que la consolidación / consistencia es algo por lo que nos esforzamos.

Hola @aslakhellesoy , implementé la funcionalidad de reintento base como la opción CLI --retry. Lo probé en el trabajo con nuestro proyecto y funciona bien. Necesitaría permisos para impulsar mi rama de trabajo y abrir un PR para discutir la implementación. Házmelo saber, gracias.

@hurrikam Gran trabajo .. 👏👏👏
También estoy deseando usar esto. Estoy usando nightwatch-cucumber y están esperando que se solucione en pepino js. Ref # https://github.com/mucsi96/nightwatch-cucumber/issues/213

@charlierudolph, ¿ podría ayudarme con esto? No puedo enviar mi PR en este momento.

@hurrikam puede crear una bifurcación y enviar su código allí y luego enviar un PR desde su bifurcación a este repositorio. https://help.github.com/articles/fork-a-repo/

@charlierudolph , consulte PR-1114
Como se menciona en el título, esta es la implementación minimalista (de hecho, muy pocos cambios de código) para que la característica funcione sin romper los formateadores e informes existentes.

Pasé por algunas conversaciones antiguas en el repositorio de Cucumber Ruby con respecto a si se debe informar cada ejecución de una prueba inestable, posiblemente introduciendo un estado de resultado 'inestable' para las ejecuciones anteriores. No estoy seguro de si eso se hizo y nuevamente, el inconveniente sería obtener todos los intentos del mismo caso de prueba en los registros.

Vamos a discutirlo.

@hurrikam mi equipo ha tomado una bifurcación de las relaciones públicas para que podamos obtener esta funcionalidad. Está funcionando muy bien hasta ahora. ¡Espero que puedas fusionarlo pronto ya que la bandera es de gran ayuda!

@ Nick-Lucas Eso es increíble. ¿Lo tienes?

@thomaswmanion sí, estamos usando activamente la función. Tenemos un backend que a veces puede ahogarse un poco al limpiar las colas de trabajo, por lo que ha sido un salvavidas.

Para cualquiera que quiera usar el PR, puede apuntar su package.json a mi bifurcación (o bifurcarme):

  "dependencies": {
    "cucumber": "https://github.com/Nick-Lucas/cucumber-js.git#feature/issue-727-retry",
  },

El pepino está preconstruido, por lo que solo se puede instalar en node_modules. No hace falta decir que definitivamente no hay garantía ni soporte, ya que la función aún no es pre-alfa.

EDITAR:

Ahora dejé mi empresa y entregué la bifurcación a su github: https://github.com/wonderbill/cucumber-js.git#feature/issue -727-retry

¡¡¡¡Bonito!!!! Gracias @ Nick-Lucas. ¡Apreciamos la comprensión de que los entornos de los sistemas pueden ser de naturaleza inestable!

Esto debe fusionarse con Master, esto no está cerrado.

@thomaswmanion sí, estamos usando activamente la función. Tenemos un backend que a veces puede ahogarse un poco al limpiar las colas de trabajo, por lo que ha sido un salvavidas.

Para cualquiera que quiera usar el PR, puede apuntar su package.json a mi bifurcación (o bifurcarme):

  "dependencies": {
    "cucumber": "https://github.com/Nick-Lucas/cucumber-js.git#feature/issue-727-retry",
  },

El pepino está preconstruido, por lo que solo se puede instalar en node_modules. No hace falta decir que _definitivamente no hay garantía ni soporte_ ya que la función ni siquiera es pre-alfa todavía

EDITAR:

Ahora dejé mi empresa y entregué la bifurcación a su github: https://github.com/wonderbill/cucumber-js.git#feature/issue -727-retry

¿Cómo puedo ejecutar la función de reintento al realizar pruebas?

@ricardgarcia solo usa la opción --retry ver https://github.com/owncloud/phoenix/pull/1207/files
Estamos usando la rama de mi PR aquí https://github.com/cucumber/cucumber-js/pull/1205 hasta que se fusione con suerte algún día

Hola @ individual-it, muchas gracias por la respuesta. ¿Debería funcionar si estoy usando webdriverIO para ejecutar mis pruebas en cucumber-js?
Probé el comando "--retry 1" pero no se están realizando reintentos.

@ricardgarcia Como se describe en https://github.com/cucumber/cucumber-js/pull/1205 , para usar esta función puedes usar

"cucumber": "cucumber/cucumber-js#issue-727-retry"

ya que los cambios aún no se han fusionado en el repositorio principal de pepino.

Sí @ jain-neeeraj He usado esta versión en package.json y no funcionó, pero como mencioné, estoy ejecutando pruebas usando pepino en webdriverIO, por lo que el siguiente marco "wdio-cucumber-framework". ¿Debería funcionar de alguna manera? ¿Cómo ejecuto las pruebas para volver a intentarlo si uso el marco cucumber-js?

@ricardgarcia permite colaborar en gitter https://gitter.im/cucumber/cucumber-js , debería poder ayudarte a resolver este problema.

@charlierudolph, ¿hay alguna posibilidad de que esto se pueda fusionar con el maestro?