Cucumber-js: En el resultado faltan el escenario y las etiquetas

No. No puede acceder fácilmente a las etiquetas del caso de prueba. No hay ningún plan para volver al resultado del escenario anterior. ¿Cuál es su caso de uso para necesitar las etiquetas?

En mi caso, tengo dependencia del sistema de etiquetas. Para obtener algunos datos en los afterhooks.

Algo como esto:

<strong i="7">@SuiteName</strong> <strong i="8">@SuiteSectionName</strong> <- These tags tell the suite
Feature: 

<strong i="9">@TC1563697</strong> <- This tag identifies the testcase in the test management tool <strong i="10">@New</strong>
Scenario: 
    Given  
    When 
    Then 

Puede crear enlaces que se ejecuten solo para escenarios con etiquetas específicas: https://github.com/cucumber/cucumber-js/blob/v3.0.1/docs/support_files/hooks.md#tagged -hooks

También tengo varios casos de uso para conocer las etiquetas de escenario. Dado el siguiente ejemplo de sudo (falta un poco la sintaxis de la versión, ya que tengo casos de prueba en 1.3.1 y estoy viendo la última versión 3.0.1):

<strong i="6">@set_video</strong> <strong i="7">@youtube</strong>
Scenario: User should see youtube video

<strong i="8">@set_video</strong> <strong i="9">@vimeo</strong>
Scenario: User should see vimeo video


this.After({tags: @set_video}, function (testCase) {
  let tags = testCase.scenario.tags;

_.forEach(tags, (function (tag) {
 if(tag === '<strong i="10">@youtube</strong>') {
   setVideo('youtube');
 }
if(tag === '<strong i="11">@vimeo</strong>') {
 setVideo('vimeo');
}
});

}

Tengo una etiqueta que dice cuándo se debe ejecutar el gancho y tengo otras etiquetas que actúan como datos para hacer que el gancho sea más dinámico para que funcione en otros casos de uso. De lo contrario, me encuentro creando el mismo gancho con la misma lógica y solo cambiando los datos que le paso. Encuentro que conocer las etiquetas es muy útil y una herramienta muy poderosa para hacer que los ganchos sean más flexibles.

¿Puedo preguntar también aquí? Parece que no puedo obtener el objeto de resultado en el gancho After en 3.0.1. Probé testCase, ScenarioResult y Scenario. ¿Me estoy perdiendo de algo?

Tenemos un caso en el que guardamos nuestros casos de prueba en TestRail y los descargamos y guardamos como archivos de características antes de la ejecución.

Luego, en el gancho posterior, enviamos los resultados detallados de las pruebas a nuestra base de datos SQL. Esos resultados incluyen:

• ID de función de TestRail: tomado de una etiqueta (cada función tiene una etiqueta generada automáticamente con la ID de función)
• excepción que fue lanzada - tomada de scenario.getException() en pepino 1.x
• todas las etiquetas con las que está etiquetada la función
• pasos que fallaron: usamos stepResult hook para obtener el resultado de cada paso
• un montón de otra información obtenida de TestRail usando el ID de función tomado de las etiquetas

Entonces, con el cambio actual en pepino 3.x, nunca podremos cambiar, ya que rompe completamente nuestra infraestructura.

@pawelus Mi infraestructura hace exactamente lo mismo.
Parece que, dado que no pierde nada al realizar estas acciones de forma asincrónica (es decir, a su infraestructura de prueba real no le "importa" la actualización de TestRail), puede mover ese código a un formateador personalizado y usar la información que proviene del evento protocolo para construir y enviar los informes.

Personalmente tengo un script de envoltura que lanza pepino.
Descarga los escenarios de TestRail antes de que se inicie el pepino, por lo que no fue un gran problema para mí mover el código de informe de TestRail de los ganchos de pepino al script de envoltura.
Una vez que cucumber se completa, el script lee el JSON de cucumberResults generado y compila toda la información que necesita a partir de ahí.

Parece que tendrás que reorganizar tu código de cualquier manera.
Creo que mover todas las acciones previas / posteriores a un script de envoltura es una buena solución que restaura parte del control que perdimos en V3.
Todavía es algo molesto, ya que tengo que serializar información de contexto importante para enriquecer los resultados generados (ya que el estado de mi infraestructura se destruye cuando se ejecuta el código relevante), pero es factible.

Creo que perder la capacidad de reconocer las etiquetas en los ganchos sería una pena. Era la única forma de hacer un poco más configurable, ya que no se pueden pasar los parámetros. Estaba agregando etiquetas adicionales y luego ver cuáles se aplicaron al escenario actual para llamar a funciones con diferentes entradas.

@yaronassa ejecutamos nuestras pruebas a través de Transportador, no lanzamos pepino directamente, por lo que hay otra capa de abstracción para contar aquí.

Descargamos funciones antes de que Protractor comience como lo hace, pero enviar resultados a la base de datos es una historia diferente.

Con la fragmentación y las pruebas que se ejecutan en la cuadrícula de Selenium y las repeticiones de funciones fallidas, será bastante complicado y una lógica compleja obtener los resultados en el orden correcto en la base de datos. Mucho trabajo para restaurar las capacidades que teníamos en el pepino 1 y 2.

Además, crear un formateador personalizado solo para obtener resultados de pasos simplemente no suena bien.

Oye, estoy contigo.
Hubiera querido acceso sin restricciones al estado actual del pepino: función, escenario y paso, con toda su colección de propiedades y acceso de escritura (incluso me gustaría tener acceso a la futura "pila de llamadas" de los escenarios, con la capacidad de manipularla de antemano ).

Dado que cucumberJS se está alejando deliberadamente de este tipo de "visibilidad interna", estoy ofreciendo el tipo de soluciones que creo que pueden funcionar en el futuro previsible. Personalmente, creo que llegará un momento en el que los manitas como nosotros tendremos que recurrir a métodos internos primordiales en el interno de Cucumber para retener este tipo de acceso.
Y eso está bien, supongo que somos una docena de nosotros y miles de usuarios ocasionales más.

Si es posible, también respaldaría el nombre del escenario. De hecho, estoy agregando una capacidad de instantánea y necesito saber el nombre del escenario para nombrar mis instantáneas.

@ gd46 puede hacer lo siguiente:

this.After({tags: "<strong i="7">@set_video</strong> and @youtube"}, function () {
  setVideo('youtube');
})

this.After({tags: "<strong i="8">@set_video</strong> and @vimeo"}, function () {
  setVideo('vimeo');
})

Eso no tiene ninguna duplicación aparte de la bandera @set_video .

@pawelus

Luego, en el gancho posterior, enviamos los resultados detallados de las pruebas a nuestra base de datos SQL.

¿Necesita hacer esto en un gancho After ? ¿Podría hacer esto después de que finalicen sus pruebas analizando los resultados del formateador json? Puede usar el formateador de protocolo de eventos para continuar con esto a medida que ocurren los resultados, aunque eso requeriría un poco más de procesamiento. Un subproducto de los cambios de 3.x es que el análisis de los resultados se mueve de los archivos de soporte a procesos independientes. Creo que esta es una mejor separación de las cosas e idealmente cómo se construyeron las cosas originalmente.

@bnadim

Puede agregar capturas de pantalla con la función attach para que se generen en los formateadores de eventos potocol / json y luego hacer un procesamiento posterior para guardarlas en archivos según el nombre del escenario. Lado no: no se garantiza que el nombre del escenario sea único, mientras que el uri del escenario y el número de línea sí lo son.

@charlierudolph Supongo que es una solución de reemplazo sólida para mis necesidades. También elimina la necesidad de analizar el escenario actual en ejecución. Simplemente podría llevar a definir varias combinaciones de ganchos que tengan en cuenta las diferentes combinaciones que una función determinada podría manejar dentro de un gancho.

Entonces, por ejemplo, tengo ejemplos similares en los que obtengo las etiquetas de los escenarios en ejecución actuales que se dividen en función de un patrón y uso parte de la coincidencia como parámetro de una función. En estos casos, todos los pasos que deben suceder son los mismos y lo único que cambia es el parámetro. Por lo tanto, esto reduciría varios pasos de configuración en el gancho para que pudiera funcionar en varios casos.

Uno de esos ejemplos:

tags: <strong i="9">@clear_w2OnlyUser</strong>, <strong i="10">@clear_w2OnlyArcotEnableUser</strong>

I split based on <strong i="11">@clear_</strong> and grab the second half as the parameter. tagName coming from the old scenario result of getTags, getName. 

let profileToClear = tagName.split('<strong i="12">@clear_</strong>')[1];

browser.waitForAngularEnabled(false);
browser.get(url);
login();
navigate();
deleteProfile(profileToClear);

¿Dime qué piensas sobre esto? Creo que su ejemplo sería fácil de reemplazar en algunos casos. Pero en otros, donde hay varios pasos adicionales que deben suceder, podría terminar duplicando potencialmente todos estos pasos.

Mi caso de uso es que configuro un servidor simulado para cada escenario, según la etiqueta, sé cómo debería comportarse. Agregar ganchos para escenarios etiquetados específicos requiere mucho mantenimiento, porque necesito agregar un gancho para cada escenario que admita ...

También estamos usando el escenario.nombre en nuestros ganchos Antes y Después para registrar el nombre del escenario. De esta manera podemos ver cuándo comienza y termina un determinado escenario al analizar los resultados de la prueba. Este cambio rompe esa característica.

Estoy usando Cucumber-js para manejar Selenium. Tanto local como Browserstack

Estaba usando el estado de prueba (función, escenario, etiquetas, resultados, etc.) en los ganchos para muchas cosas esenciales.

• tener alteraciones específicas del escenario de la URL
• Omitir pruebas dinámicamente según la configuración actual del navegador.
• Utilice la URL específica del escenario para registrar los resultados de la prueba en el Browserstack
• Utilice nombres de funciones y escenarios para generar nombres de sesión en Browserstack
• Analizar etiquetas para identificar y establecer la resolución del navegador específica del escenario

Todos estos se incluyeron en aplicaciones para permitir instancias simultáneas para reducir el tiempo de ejecución general.

¿Por qué fueron descartados?
¿No volverán nunca?

@ gd46

¿El escenario que se está ejecutando implica ese tipo de perfil? ¿Quizás podría hacer que el escenario guarde qué tipo de perfil está interactuando con el mundo y luego tenga una sola etiqueta clara que solicite la eliminación del perfil guardado?

@justusromijn

Para su servidor simulado, ¿podría mover la configuración de la etiqueta basada en el uso de un paso que defina cuál es la configuración? Entonces puede parametrizar fácilmente.

@Jordyderuijter

Puede registrar la línea del escenario y la uri (que en realidad es única y evita que tenga que buscar el nombre del escenario).

@leggebroten

tener alteraciones específicas del escenario de la URL

Puede usar un paso para esto en su lugar o usar etiquetas únicas

Omitir pruebas dinámicamente según la configuración actual del navegador.

¿Cómo te saltaste dinámicamente las pruebas? # 912 agrega soporte para esto

Utilice la URL específica del escenario para registrar los resultados de la prueba en el Browserstack

Puede usar la línea y uri en lugar del nombre. Como se señaló anteriormente, la línea y el uri están garantizados como únicos, mientras que el nombre no lo es. También sugiero analizar el formateador json o el formateador de protocolo de eventos para obtener los resultados de las pruebas y usar archivos adjuntos si necesita agregar algo.

Utilice nombres de funciones y escenarios para generar nombres de sesión en Browserstack

Puedes usar la línea + URI

Analizar etiquetas para identificar y establecer la resolución del navegador específica del escenario

Puedes usar un paso para esto.

De todos estos ejemplos, todavía tengo un caso de uso que me convence de que deberíamos volver a agregar etiquetas o nombres al gancho. Tener las etiquetas y el nombre parece haber facilitado ciertas cosas, pero creo que hay otras formas de lograrlas que tienen más sentido para mí.

@charlierudolph gracias por la respuesta. Para el servidor simulado ya tuve una charla rápida con algunos compañeros de trabajo y el uso de un "fondo" compartido estaba en consideración para una solución, así que sí, puedes cruzar esa de la lista.

@charlierudolph Gracias por la respuesta.

Si bien sus sugerencias sobre el uso de Pasos y el análisis de resultados podrían funcionar, es muy inferior a las versiones anteriores en las que las devoluciones de llamada tienen acceso al estado de prueba.

0) Inconsistente con el patrón Observer. Las devoluciones de llamada deben recibir los datos que necesitan para el comportamiento que están respaldando.

1) Induce extrema fragilidad. Las pruebas deben ser confiables o no se confiará en ellas. Los números de línea y los nombres de archivo cambian. Simplemente agregar o eliminar un retorno de carro romperá las pruebas.

2) Usar Pasos para alterar el estado viola SECO. Considere el caso frecuente de agregar pruebas A / B que están marcadas con una etiqueta. A menos que agregue una extensión de línea de comando para ejecutar pruebas basadas en los Pasos que incluyen, las pruebas requerirán AMBAS etiquetas y sus Pasos de apoyo que alteran el estado.

3) Requiere que el desarrollador haga un trabajo adicional. Analizar la salida para encontrar el estado es innecesario, tedioso, propenso a errores, vincula las pruebas a los formatos de salida (acoplamiento deficiente) y viola DRY.

4) Inconsistente con Pepino. Agregar Pasos (una parte semántica de la prueba) para alterar el estado de la Característica es contrario a la intención de Cucumber de aislar al escritor de pruebas. Si el comportamiento no ha cambiado, la prueba no debería.

5) No es declarativo. Las etiquetas son metadatos ACERCA de la prueba, es semánticamente coherente usarlas para alterar el estado en el que se ejecutará la prueba. Considerando que los pasos están integrados dentro de la prueba. Identifica un conjunto de pruebas por sus Etiquetas ... no por los Pasos que utilizan.

Ah, y en realidad no estaba "omitiendo" las pruebas, estaba usando la devolución de llamada (nula, 'pendiente') para evitar ejecutar la prueba. La nueva función 'omitir' es una solución superior.

@charlierudolph , estaba pensando, otra solución ...
al construir el objeto Mundo, proporcione una referencia al objeto Escenario utilizado para la prueba.

Dado que el mundo está disponible como "esto" para todas las devoluciones de llamada, lograría la paridad total con V2 (siempre que se dieran los resultados a la devolución de llamada de AfterAll)

@leggebroten

1. Nunca escuché que el patrón del observador fuera un objetivo de diseño para el pepino.
2. Los nombres de los escenarios también son frágiles ya que un solo cambio de carácter también lo cambia. Estoy de acuerdo con el salto de número de línea / archivo cuando tomo lo que se siente como acciones no relacionadas. Estaba sugiriendo el uso en la presentación de informes de resultados y no en la ejecución de pruebas y, por lo tanto, la parte frágil no tiene mucho efecto negativo.
3. Using Steps to alter State violates DRY No entiendo esto. La etiqueta se usa para seleccionar características y el paso se usa para configuración / acciones / expectativas. Estos son propósitos diferentes. Tenemos un soporte mínimo para usar la etiqueta para la configuración con ganchos etiquetados, pero no está diseñado para manejar la complejidad.
4. Solo estaba sugiriendo analizar la salida del formateador para informes. Eso no debería estar involucrado en la ejecución de pruebas.
5. Adding Steps (a semantic part of the test) to alter the Feature's state is counter to intent of Cucumber of isolating test writer Yo tampoco entiendo esto. Si no puede seguir los pasos para realizar acciones y establecer el estado, ¿cómo está ejecutando las pruebas?
6. Tags are metadata ABOUT the test, it is semantically consistent to use them to alter the state in which the test will run . No estoy de acuerdo con que eso sea consistente. Para mí, las etiquetas son solo para identificar pruebas. Hay soporte para la alteración mínima del estado pero no para la alteración compleja del estado con parámetros.

No hay más objetos de escenario en el sistema. No creo que la paridad con v2 deba ser un objetivo. Me alegro de que surgiera esta conversación y estoy buscando otras soluciones, pero no quiero volver a lo que teníamos anteriormente, ya que creo que eso estaba haciendo que los usuarios confiaran mucho más en la implementación de pepino y no en su interfaz.

@charlierudolph ,

Gracias por tomarse el tiempo para discutir este tema. Realmente aprecio el trabajo que ha hecho para proporcionarnos Cucumber-js. Pero tal como está, no puedo actualizar a V3.

No pretendo ser combativo. Solo estoy preocupado y puede aparecer en mis respuestas.

Utilizando solo la interfaz de eventos documentada de la versión anterior, he creado un marco que reduce drásticamente el tiempo total de ejecución de la prueba al permitir que las funciones se ejecuten simultáneamente en una enorme matriz de prueba configurable que incluye sistemas operativos / versiones, navegadores / versiones, escritorio / Pruebas móviles y optimizadas A / B.

NO PUEDO usar Steps. Es demasiado tarde. El tipo de dispositivo, el SO / versión y el navegador / versión DEBEN determinarse antes de que comience la prueba o cada Escenario se verá obligado a tener un paso de "configuración del sistema operativo" y un paso de "configuración del navegador". Esto está en conflicto directo con los objetivos de Cucumber.

Alternativamente, como mencioné anteriormente, puede proporcionar la información del escenario (URI de característica, nombre, línea y etiquetas) al constructor de World. Esto es semánticamente consistente con la intención del objeto World y más simple de encapsular y extender. Esto no solo eliminará la mayoría de mis Controladores de eventos, sino que debido a que el "esto" del Controlador es el objeto Mundo, es un Estado consistente con el Patrón del observador.

1. No dije que Observer Pattern fuera un objetivo de diseño para Cucumber. Simplemente que Hooks and Events son Observadores y que, como tales, se les debe dar el estado que necesitan para hacer su trabajo. Este patrón permite la separación entre la implementación de la persona que llama y los controladores de eventos.

2. No tengo dependencia de los nombres reales. Pero dado que son únicos, son el medio para crear el nombre de sesión significativo para el usuario asociado en Browserstack.

3. Tener acceso al conjunto de etiquetas durante Antes, me permitió crear construcciones reutilizables para alterar el estado (como configurar los parámetros de URL de Optimizely) sin modificar la prueba (agregar pasos). Esto significaba que había una correlación de 1-1 entre las pruebas que quería ejecutar (etiquetas) y su configuración. SECO.

4. Ha expresado su preocupación de que los desarrolladores se estén volviendo dependientes de la implementación, pero su solución para eliminar el estado del observador necesario es hacer que el desarrollador dependa de otra implementación (formato de archivo). ¿Cómo puede ser mejor forzar a un usuario a realizar un trabajo de análisis de archivos MUCHO más tedioso, lento y propenso a errores que acceder a una propiedad estatal?

5. Obviamente, los pasos están configurando el estado de prueba. Pero uno de los objetivos del diseño de Cucumber era que la persona que escribía los Pasos debería estar aislada de la implementación subyacente. EG prueba el comportamiento semántico sin atascarse en los detalles subyacentes. Agregar Pasos para modificar los parámetros de consulta y definir el dispositivo / navegador / sistema operativo parece contrario a este objetivo.

6. Para usted, las etiquetas solo sirven para identificar pruebas. Pero Cucumber Wiki tiene muchos usos para las etiquetas.

7. Organizar y agrupar
8. Filtros (conjuntos en ejecución a través de la línea de comandos)
9. Vínculos a documentos relacionados (como indicadores Optimizely)
10. Indicando en qué parte del proceso se encuentra la característica

Tener acceso a las etiquetas durante la devolución de llamada anterior me permite asegurar el estado apropiado en función de la configuración del navegador que se está utilizando para realizar la prueba. El uso de etiquetas lo convierte en declarativo. El uso de Steps confunde la intención

Las llamadas y los parámetros de los controladores de eventos en versiones anteriores ERA interfaz. Si los desarrolladores combinan su código con su implementación que se filtra, pase un proxy de "escenario" de solo lectura a los controladores de eventos.

@charlierudolph gracias por tu respuesta

Los nombres de los escenarios también son frágiles ya que un solo cambio de carácter también lo cambia. Estoy de acuerdo con el salto de número de línea / archivo cuando tomo lo que se siente como acciones no relacionadas. Estaba sugiriendo el uso en la presentación de informes de resultados y no en la ejecución de pruebas y, por lo tanto, la parte frágil no tiene mucho efecto negativo.

Es cierto que los nombres de los escenarios también son frágiles, pero es una forma mucho menos frágil de hacer referencia a los escenarios que hacer referencia a ellos por archivo y línea. Estamos usando los nombres de los escenarios en el registro a diario para analizar las fallas en la ejecución y ver qué salió mal. Si el registro solo muestra el archivo y el número de línea, causará demasiada sobrecarga para rastrear el escenario. Además de eso, si alguien hizo cambios en el archivo de características o movió el escenario a otro lugar mientras tanto, esto se complicará aún más.

Si el registro solo muestra el archivo y el número de línea, causará demasiada sobrecarga para rastrear el escenario.

¿Cómo es más alto? Conoce el archivo y el número de línea y puede ir directamente allí. Si tiene el nombre del escenario, debe buscar esa cadena para llevarla a ese archivo y línea.

¿Cómo es más alto? Conoce el archivo y el número de línea y puede ir directamente allí. Si tiene el nombre del escenario, debe buscar esa cadena para llevarla a ese archivo y línea.

Como dije, si el archivo de características cambia mientras tanto y el escenario ya no está posicionado en esa línea. Especialmente cuando estoy mirando los registros de una ejecución de prueba anterior (por ejemplo, hace 1 semana). En este caso, tendría que pasar por git y ver qué escenario estaba en esa línea en ese momento dado.

FWIW, cucumber-ruby tiene dos puntos de extensión que creo que satisfacen el principio de "las cosas fáciles deberían ser fáciles, las difíciles deberían ser posibles" y podrían ser ideas que podrían ayudar con estos casos de uso.

En primer lugar, pasamos una instancia de RunningTestCase a cada gancho. Este es un objeto de valor inmutable que contiene toda la información sobre la fuente de Gherkin (escenario / esquema / etiquetas, etc.) más el estado de resultado actual del escenario. Ser inmutables significa que estamos protegidos de tener que considerar casos en los que el usuario podría intentar cambiarnos las cosas, pero igualmente les da transparencia sobre cuál es la situación actual.

En segundo lugar, tenemos filtros . Los filtros le permiten manipular el flujo de casos de prueba antes de que se ejecuten. Usamos filtros para, por ejemplo, eliminar casos de prueba de la transmisión que no coinciden con el patrón de etiqueta especificado en la CLI. Los filtros son una función de usuario avanzado.

HTH

¡Me acabo de dar cuenta de que la documentación detrás de ese enlace para filtros es terrible! Perdón. No hay tiempo para arreglarlo ahora, pero hay algunos ejemplos más aquí: http://www.rubydoc.info/github/cucumber/cucumber-ruby/Cucumber/Filters

Hola @charlierudolph ,

Lo siento, ha pasado un tiempo desde que hice un seguimiento de esta conversación. ¿Puede ampliar su declaración?

"¿El escenario que se está ejecutando implica ese tipo de perfil? ¿Quizás podría hacer que el escenario guarde qué tipo de perfil está interactuando con el mundo y luego tiene una sola etiqueta clara que solicita la eliminación del perfil guardado?"

No estoy seguro de seguir.

Y entiendo que tal vez haya otras formas de obtener la misma solución sin el resultado de la prueba anterior. Pero por lo que he visto hasta ahora en esta conversación, todas las alternativas parecen más complejas de lo que deben ser. El resultado de la prueba anterior tenía muchos datos descriptivos sobre el escenario que estaba a punto de ejecutarse y era la única forma de tener ganchos "parametrizados". El transportador tal como está, según lo que he visto e intentado, actualmente no admite la ejecución de una función desde un número de línea de escenarios. Entonces, el nuevo resultado de testCase no tiene mucho que me parezca útil aparte del estado.

Me gustaría ver que testCase coincida con el resultado devuelto al usar getTestCasesFromFileSystem con PickleFilter. He usado esto para hacer un trabajo paralelo interesante para admitir el filtrado de escenarios por etiqueta para pasar al transportador como fragmentos. La información devuelta de ese resultado es mucho más útil y creo que sería extremadamente útil tenerla en el resultado de testCase.

Resultado de ejemplo de PickFilter:

{ pickle: 
     { tags: [Object],
       name: 'Github test with page object',
       language: 'en',
       locations: [Object],
       steps: [Object] },
    uri: 'test/features/examples/github-example.feature' }

No estoy diciendo que deba coincidir exactamente, pero veo mucho en este resultado de lo que otros aquí y yo parecemos beneficiarnos.

Si le interesa mi ejemplo, lo estoy usando aquí: https://github.com/gd46/dibellag-automation-framework/blob/master/configuration.js#L91

@charlierudolph ¿Es aquí donde se configura testCase?

https://github.com/cucumber/cucumber-js/blob/fbff6b0fae54d2e341ee247addc60a9f05753f1d/src/formatter/helpers/event_data_collector.js#L22

Por lo que puedo decir, hay una referencia a pickle junto con testCase. Entonces, ¿por qué no devolver algunos bits más del resultado de pickle al resultado de testCase?

@ gd46 bien, agreguemos pickle al objeto que se pasa al gancho reemplazando sourceLocation. Eso debe actualizarse en esta función: https://github.com/cucumber/cucumber-js/blob/master/src/runtime/test_case_runner.js#L153

Hola @charlierudolph , acabo de ver tu comentario. ¡Eso seria genial! Intentaré echarle un vistazo a esto pronto. Estaré feliz de hacer la contribución.

@charlierudolph Solo quería aclarar el cambio. ¿Estamos de acuerdo con la diferencia de que pickle contiene uri sin el número de línea directamente en él como lo hace sourceLocation? ¿Y si alguien desea consumir el uri con el número de línea, puede usar los números de línea devueltos por el objeto pickle? No veo ningún problema con esto, solo quería confirmarlo.

Supongo que dejemos el objeto de ubicación de origen como está (en lugar de eliminarlo) y agreguemos el objeto pickle.

Ok, eso también funciona para mí. Así que soy nuevo en contribuir al pepino, todavía estoy tratando de entender la estructura.

Como ha señalado la línea que debe actualizarse, creo que podemos agregar algo como esto junto a sourceLocation:

pickle: this.testCase.pickle

Entonces cualquiera que desee consumirlo en el gancho puede acceder a él de la siguiente manera:

testCase.pickle.tags
testCase.pickle.name
etc. 

Hice la actualización, pero no estoy 100% seguro de cómo actualizar todas las pruebas relacionadas. ¿Podría proporcionarnos alguna orientación?

Pude probar el cambio vinculando mi bifurcación con los cambios en uno de mis proyectos locales. El resultado completo de testCase se verá así:

{
  "sourceLocation": {
    "uri": "test\/features\/examples\/example.feature",
    "line": 4
  },
  "pickle": {
    "tags": [
      {
        "name": "@example",
        "location": {
          "line": 3,
          "column": 3
        }
      }
    ],
    "name": "Custom Transform should take belly and capitalize it",
    "language": "en",
    "locations": [
      {
        "line": 4,
        "column": 3
      }
    ],
    "steps": [
      {
        "text": "I have cucumbers in my belly",
        "arguments": [

        ],
        "locations": [
          {
            "line": 5,
            "column": 10
          }
        ]
      }
    ]
  },
  "result": {
    "duration": 7,
    "status": "passed"
  }
}

Después de hacer algunas pruebas más, noté que pickle no contiene uri en el momento en que tenemos acceso a él en test_case_runner. Así que creo que está bien mantener la ubicación de origen como está.

Esto es lo que PickleFilter devuelve pickle como:

{
    "pickle": {
      "tags": [
        {
          "name": "@example",
          "location": {
            "line": 3,
            "column": 3
          }
        }
      ],
      "name": "Custom Transform should take belly and capitalize it",
      "language": "en",
      "locations": [
        {
          "line": 4,
          "column": 3
        }
      ],
      "steps": [
        {
          "text": "I have cucumbers in my belly",
          "arguments": [

          ],
          "locations": [
            {
              "line": 5,
              "column": 10
            }
          ]
        }
      ]
    },
    "uri": "test\/features\/examples\/example.feature"
  }

Entonces todo será lo mismo menos el pepinillo sin uri.

Abrió un PR para resaltar los cambios hasta ahora. Aún necesito actualizar las pruebas.

Trabajando en la actualización de pruebas. Tengo esta cosa configurada para cambiar mi versión local de Java y me di cuenta de que por eso no pude ejecutar algunas de las pruebas de funciones: /.

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.