Cucumber-js: ¿Cómo funcionará la opción paralela con el protocolo de eventos?

Creado en 5 feb. 2018  ·  9Comentarios  ·  Fuente: cucumber/cucumber-js

Los formateadores personalizados que solo se enganchan en test-run-finished como el formateador JSON funcionan según lo previsto cuando están en paralelo, pero los formateadores que usan eventos anteriores como test-(step|case)-started y están ordenados tienen su salida desconectada de la secuencia invalidando la estructura del documento de salida. ¿Hay algo planeado para abordar eso? ¿Se puede almacenar en búfer la salida por trabajador y registrarlo todo a la vez en el maestro una vez completado?

Comentario más útil

¡Necesitamos mucho esta función!

Todos 9 comentarios

Creo que cada evento debe contener suficiente información para poder vincularlo a eventos anteriores en lugar de almacenarlo en búfer.

No estoy seguro de cómo funcionaría eso si solo se enganchan los eventos 'finales', ya que se perderían el comienzo de la salida de la prueba. Para usar corredores de prueba de editores basados ​​en IntelliJ y formateadores bonitos como ejemplos, funcionan de la siguiente manera:

  1. Registrar la declaración de 'apertura' en el evento de inicio, en caso de bonito - Scenario: Foo , en el caso de IntelliJ - Comentario con formato de TeamCity #teamcity[testStarted]
  2. Ejecute la prueba que imprime sus propios registros después de la salida inicial del formateador
  3. Registrar la declaración de cierre del evento final, pass/fail resumen o ##teamcity[testFinished]

El orden es importante para tener una declaración de apertura antes de cualquier cosa que registre la prueba y una declaración de cierre después, y ninguna otra prueba debe registrar nada en paralelo a eso o mezclarán qué salida pertenece a qué prueba. El almacenamiento en búfer parece encargarse de eso, ya que cada salida se aislará y se registrará en el maestro en la operación atómica.

Podemos pasar una opción isParallel a los formateadores personalizados para hacerles saber que la salida de elementos en eventos de inicio de caso de prueba / paso de prueba se mezclará y, por lo tanto, solo debería generar en eventos de caso de prueba finalizado.

Necesitamos más discusión sobre este tema. Actualmente, usar cualquier formateador tiene el riesgo de bloquear el corredor de pepino debido a conflictos de E / S al intentar escribir en una terminal. El formateador de barra de progreso sería ideal para el corredor paralelo, si solo moviera la barra y luego informara un resumen al final.

El plan es hacer la transición a formateadores independientes que consumen un flujo de mensajes de pepino.

Ver hoja de ruta y dots-formatter y pretty-formatter (WIP) en el monorepo

¡Necesitamos mucho esta función!

¡Hola! ¿Existe alguna posibilidad de ejecutar pepino js en paralelo con el reportero de encanto? Cuando trato de ejecutar con cucumber-js --parallel 2 -t @debug --format reporter.js: ./ dummy.txt acabo de obtener TypeError: No se puede leer la propiedad 'sourceLocation' de undefined
¡Gracias de antemano!

El mismo problema que @ yevgen-getalo aquí.

El cierre como v7.0.0 usa el nuevo protocolo de mensajes mencionado anteriormente, donde los eventos $THING_started y $THING_finished se pueden vincular de manera confiable a través de identificadores. El objeto eventDataCollector.query (una instancia de @cucumber/query ) puede ayudar con algo de esto.

¿Fue útil esta página
0 / 5 - 0 calificaciones