Cucumber-js: resultado del escenario no pasado a ganchos antes / después

Me mordió esto. Nuestra actualización a 3 en pepino pro está en espera debido a esto.

¿Es https://github.com/cucumber/cucumber-js/blob/fbff6b0fae54d2e341ee247addc60a9f05753f1d/src/runtime/test_case_runner.js#L109 el culpable?

¿Qué parte de esto se necesita exactamente? ¿Utiliza solo los predicados de estado? Eso parece ser lo único que se usa en los documentos que rodean a este

Actualmente usamos scenarioResult.status , scenarioResult.scenario.uri y scenarioResult.scenario.line .

@jbpros, ¿su caso de uso sigue los ejemplos que tenemos actualmente en torno a esto (guardar una captura de pantalla cuando falla un escenario)? Siempre pensé que era realmente extraño que el escenario se convirtiera en ganchos y me gustaría encontrar una forma diferente de manejar esto.

Actualmente, creo que agregamos una nueva función de código de soporte: onFailedTestStep que le permite configurar una función para que se llame con un paso de prueba que falla. Se llamaría con el mismo argumento mundial que el paso fallido y, por lo tanto, podría adjuntar una imagen o algo así. Podríamos crear un módulo dedicado para analizar archivos adjuntos del formateador de protocolo de eventos y copiarlos en una carpeta.

Como tinker-user, me gustaría que cualquier función / manejador / objeto tuviera tanto contexto como sea posible. Incluso sin algo grandioso como todo el árbol de ejecución pasado y futuro (https://github.com/cucumber/cucumber-js/issues/875), sería extremadamente útil saber cuál es el paso actual y el escenario para cada falla.
Por ejemplo, esto me permite controlar los procedimientos de reversión según las etiquetas, o simplemente ver qué otros pasos se ejecutaron antes del fallido.

Le recomiendo que considere pasarlos a onFailedTestStep , si esa es la solución que busca.

Los Hook Docs también deben actualizarse: el enlace del primer párrafo a ScenarioResult es un 404.

En lugar de onFailedTestStep , ¿por qué no definir un gancho llamado AfterStep ? Cucumber-Ruby ha tenido esto durante mucho tiempo y, como saben, la consistencia es importante.

@aslakhellesoy Quiero centrarme en el caso de uso y asegurarme de que lo estamos resolviendo de la manera correcta.

La coherencia es importante, pero eso no significa que debamos copiar todo solo porque existe en otro lugar. Deberíamos evolucionar a medida que determinamos mejores formas de manejar las cosas.

¿Puede usted, @mattwynne o alguien del equipo de ruby

No soy del equipo de ruby, así que no sé para qué se creó AfterStep , pero yo personalmente uso AfterStep para realizar varias operaciones. Aquí hay unos ejemplos:

1. Tomar una captura de pantalla y generar un registro del navegador en escenarios fallidos
2. Realice registros adicionales para algún proyecto independientemente de si falló o no
3. Limpiar

Para nosotros, necesitaremos que el escenario y el resultado se pasen a AfterStep todos modos para realizar un registro adicional. Estoy seguro de que también hay otros casos de uso que los necesitan en AfterStep , que ni siquiera hemos considerado.

Esto significa que si hubiera algo como onFailedTestStep , tendremos más de una forma de lograr lo mismo: una para usar AfterStep y la otra para usar onFailedTestStep .

Esto también puede causar inconsistencias dentro de los proyectos dependiendo de quién implementó el gancho; algunos pueden usar AfterStep mientras que otros pueden usar onFailedTestStep . No creo que ninguno de esos sea deseable.

@charlierudolph

Quiero entender de dónde vienes. ¿Le importaría explicar por qué piensa lo siguiente?

Siempre pensé que era realmente extraño que el escenario se convirtiera en ganchos

Nunca me gustó mucho la mezcla de los dos paradigmas. Los ganchos de antes / después están relacionados con la configuración / desmontaje con la ejecución real de las pruebas. Usarlo también para informar parece algo que debería tratarse por separado

Tomar una captura de pantalla y generar un registro del navegador en escenarios fallidos

Si está haciendo esto en AfterStep, esto se hace para los pasos fallidos, no para los escenarios fallidos. Esto es para lo que todos los ejemplos en el repositorio están usando el objeto de escenario y por eso quiero hacer un nuevo gancho para este caso de uso específico. No he escuchado ningún otro caso de uso convincente.

Realice registros adicionales para algún proyecto independientemente de si falló o no

¿Qué tipo de registro adicional realiza?

Limpiar

¿Qué hay que limpiar después de un paso?

Para nosotros, necesitaremos que el escenario y el resultado se pasen a AfterStep de todos modos para realizar un registro adicional. Estoy seguro de que también hay otros casos de uso que los necesitan en AfterStep, que ni siquiera hemos considerado.

Estoy tratando de recopilar esos casos de uso. A veces, las personas pueden usarlo cuando hay otras formas de hacerlo o como una solución para algo para lo que podríamos construir un mejor soporte.

Esto significa que si hubiera algo como onFailedTestStep, tendremos más de una forma de lograr lo mismo: una para usar AfterStep y la otra para usar onFailedTestStep.

Cucumber-js actualmente no tiene AfterStep y no planeo implementar ambos.

Estoy en el proceso de intentar obtener soporte de pepino 3 en transportador-pepino-marco y realmente podría usar un AfterStep . Me doy cuenta de que una biblioteca que une otras dos bibliotecas no es el caso de uso más común, pero lo haría mucho más simple. Estoy tratando de averiguar cómo hacerlo con las nuevas cosas del protocolo de eventos, pero no obtengo ningún contexto de función / escenario / paso en ninguno de los eventos *-finished . Usamos los nombres, uris y números de línea de la función, escenario y pasos para informar al transportador y darle a las integraciones IDE (Intellij) algo para mostrar y navegar en su árbol. Mis $ 0.02 de todos modos.

Solo para mencionar que toda la funcionalidad discutida (y mucho más) se puede lograr con setDefinitionFunctionWrapper .
Puede envolver todos los pasos con acciones previas / posteriores, que no solo le permiten reaccionar a las entradas y salidas de un paso, sino incluso mutarlas.

Entonces, por ejemplo, lo uso para implementar un paso "El siguiente paso debería fallar con el error XYZ", que me permite implementar rápidamente verificaciones negativas profundas y simulaciones de errores sin implementar pasos negativos duplicados o manejo especial de errores invertibles en todos y cada uno de los pasos. .

Creo que no hay nada que un AfterStep gancho pueda hacer que setDefinitionFunctionWrapper no pueda.

¿Alguna actualización sobre esto? Intento actualizar de 2.0.0 a 3.0.0 en el trabajo y aún no está definido para el escenario.

@ paul-phillips-ark sí, vea el n. ° 905. Si desea ayudar a avanzar, puede diversificarse y enviar un nuevo PR que aborde los comentarios de @charlierudolph .

¿Cuando consigo console.log (ScenarioResult) todavía no estoy definido en las funciones Antes y Después? ¿Me estoy perdiendo de algo? Disculpas si el comentario anterior suena denso.

Mis casos de uso actualmente son los siguientes:

Antes de cada escenario, solicito accesorios que llenen mi base de datos para probar. Cada función tiene su propio conjunto de accesorios necesarios para ello. La ruta del dispositivo en el servidor repite la ruta de la función, por lo que también necesito la opción uri :

Before({ timeout: 60 * 1000 }, scenarioResult => {
    ...
    const file = scenarioResult.scenario.feature.uri;
    ...
});

En After hook como muchos de nosotros hago una captura de pantalla:

After(scenarioResult => {
    if (scenarioResult.status === 'failed') {
      driverUtils.takeScreenShot(scenarioResult.scenario.name);
    }
});

@charlierudolph, ¿ podría cortar un comunicado con la solicitud de extracción n. ° 905 como solución provisional? nos permite finalizar la transición de v2 a v3, que actualmente está bloqueada debido a esta regresión / cambio. la refactorización propuesta podría incluirse en otra solicitud de extracción.

Hay algunos problemas con el n. ° 905, pero intentaré solucionarlo y publicarlo este fin de semana.

Este hilo se ha bloqueado automáticamente ya que no ha habido ninguna actividad reciente después de que se cerró. Abra un nuevo problema para errores relacionados.