Cucumber-js: O resultado está faltando cenário e tags

Não. Você não pode acessar facilmente as tags do caso de teste. Não há nenhum plano para retornar ao resultado do cenário antigo. Qual é o seu caso de uso para a necessidade das tags?

No meu caso tenho dependência do sistema de tags. Para obter alguns dados no afterhooks.

Algo assim:

<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 

Você pode criar ganchos que são executados apenas para cenários com tags específicas: https://github.com/cucumber/cucumber-js/blob/v3.0.1/docs/support_files/hooks.md#tagged -hooks

Também tenho vários casos de uso para conhecer as tags de cenário. Dado o seguinte exemplo de sudo (faltando um pouco a sintaxe da versão, pois tenho casos de teste em 1.3.1 e estou olhando para o 3.0.1 mais recente):

<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');
}
});

}

Eu tenho uma tag que diz quando o gancho deve ser executado e outras tags que atuam como dados para tornar o gancho mais dinâmico para funcionar em outros casos de uso. Caso contrário, acabo criando o mesmo gancho com a mesma lógica e apenas alterando os dados que passo. Acho que conhecer as tags é muito útil e uma ferramenta muito poderosa para tornar os ganchos mais flexíveis.

Também posso perguntar aqui que não consigo obter o objeto de resultado no gancho After em 3.0.1. Eu tentei testCase, sceneryResult e scenery. Estou esquecendo de algo?

Temos um caso em que mantemos nossos casos de teste em TestRail e os baixamos e salvamos como arquivos de recurso antes da execução.

Em seguida, no gancho posterior, enviamos resultados de teste detalhados para nosso banco de dados SQL. Esses resultados incluem:

• ID de recurso de TestRail - obtido de uma tag (cada recurso gerou automaticamente uma tag com ID de recurso)
• exceção que foi lançada - retirada de scenario.getException() no pepino 1.x
• todas as marcas com que o elemento está marcado
• etapas que falharam - usamos stepResult gancho para obter o resultado de cada etapa
• um monte de outras informações obtidas de TestRail usando o ID de recurso obtido de tags

Portanto, com a mudança atual no cucumber 3.x, nunca seremos capazes de fazer a mudança, pois isso quebra completamente a nossa infraestrutura.

@pawelus Minha infraestrutura faz exatamente a mesma coisa.
Parece que, como você não perde nada ao executar essas ações de forma assíncrona (ou seja, sua infraestrutura de teste real não "se preocupa" com a atualização do TestRail), você pode mover esse código para um formatador personalizado e usar as informações provenientes do evento protocolo para construir e enviar os relatórios.

Pessoalmente, tenho um script de invólucro que inicia o pepino.
Ele baixou os cenários TestRail antes de o pepino ser lançado, portanto, não foi um grande problema para mim mover o código do relatório TestRail dos ganchos de pepino para o script de invólucro.
Após a conclusão do pepino, o script lê o JSON cucumberResults gerado e compila todas as informações necessárias a partir daí.

Parece que você terá que reorganizar seu código de qualquer maneira.
Acho que mover todas as ações pré / pós para um script de wrapper é uma boa solução que restaura parte do controle que perdemos na V3.
Ainda é um pouco chato, pois tenho que serializar informações de contexto importantes para enriquecer os resultados produzidos (já que meu estado de infraestrutura é destruído no momento em que o código relevante é executado), mas é factível.

Acho que perder a capacidade de conhecer as marcas nos ganchos seria uma pena. Era a única maneira de tornar um pouco mais configurável, já que você não pode passar parâmetros. Eu estava adicionando tags extras e ver quais foram aplicadas ao cenário atual para chamar funções com entradas diferentes.

@yaronassa , executamos nossos testes por meio do Protractor, não lançamos o pepino diretamente, portanto, há ainda outra camada de abstração para contar aqui.

Fazemos o download dos recursos antes de iniciar o Protractor, como você faz, mas enviar resultados para o banco de dados é uma história diferente.

Com fragmentação e testes em execução na grade do Selenium e reexecuções de recursos com falha, será um trabalho complicado e uma lógica complexa obter os resultados na ordem certa no banco de dados. Muito trabalho para restaurar as capacidades que tínhamos nos pepinos 1 e 2.

Além disso, criar um formatador personalizado apenas para obter resultados de etapas não parece certo.

Ei, estou com você.
Eu gostaria de ter acesso irrestrito ao estado atual do pepino - recurso, cenário e etapa, com toda a coleção de propriedades e acesso de gravação (eu gostaria até de acesso à futura "pilha de chamadas" dos cenários, com a capacidade de manipulá-la de antemão )

Vendo como o cucumberJS está se afastando deliberadamente desse tipo de "visibilidade interna", estou oferecendo o tipo de soluções que acho que podem funcionar em um futuro previsível. Pessoalmente, acho que chegará um momento em que os consertadores como nós terão que recorrer a métodos internos de substituição no interno de Cucumber para reter esse tipo de acesso.
E tudo bem - acho que somos uma dúzia e milhares de usuários casuais.

Se possível, eu também apoiaria o nome do cenário. Na verdade, estou adicionando um recurso de instantâneo e preciso saber o nome do cenário para nomear meus instantâneos.

@ gd46, você pode fazer o seguinte:

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');
})

Isso não tem nenhuma duplicação além da bandeira @set_video .

@pawelus

Em seguida, no gancho posterior, enviamos resultados de teste detalhados para nosso banco de dados SQL.

Você precisa fazer isso em um gancho After ? Você poderia fazer isso após a conclusão dos testes, analisando os resultados do formatador json? Você poderia usar o formatador de protocolo de evento para continuar assim que os resultados ocorrerem, embora isso exija um pouco mais de processamento. Um subproduto das alterações do 3.x é que os resultados da análise saem dos arquivos de suporte e vão para os processos autônomos. Acho que é uma melhor separação das coisas e, idealmente, de como as coisas foram construídas originalmente.

@bnadim

Você pode adicionar capturas de tela com a função attach para que sejam reproduzidas nos formatadores potocol / json do evento e, em seguida, fazer algum pós-processamento para salvá-las em arquivos com base no nome do cenário. Lado não: o nome do cenário não tem garantia de ser único, mas o uri do cenário e o número da linha são.

@charlierudolph Suponho que seja uma solução de substituição sólida para minhas necessidades. Também elimina a necessidade de analisar o cenário atual em execução. Isso apenas pode levar à definição de várias combinações de ganchos que explicam as diferentes combinações que uma determinada função pode manipular dentro de um gancho.

Portanto, por exemplo, tenho exemplos semelhantes em que obtenho as tags dos cenários de execução atuais, divido-as com base em um padrão e uso parte da correspondência como parâmetro para uma função. Nestes casos todos os passos que precisam acontecer são os mesmos e a única coisa que muda é o parâmetro. Portanto, isso reduziria várias etapas de configuração no gancho para que pudesse funcionar em vários casos.

Um exemplo:

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);

Deixe-me saber o que você pensa sobre isso? Eu acredito que seu exemplo seria uma substituição fácil em alguns casos. Mas em outros, onde há várias etapas extras que precisam acontecer, você pode acabar duplicando todas essas etapas.

Meu caso de uso é configurar um servidor mocks para cada cenário, com base na tag que sei como ele deve se comportar. Adicionar ganchos para cenários marcados específicos exige muita manutenção, porque preciso adicionar um gancho para cada cenário que apóio ...

Também estamos usando o cenário.name em nossos ganchos Antes e Depois para registrar o nome do cenário. Dessa forma, podemos ver quando um determinado cenário começa e termina ao analisar os resultados do teste. Essa mudança quebra esse recurso.

Estou usando Cucumber-js para dirigir Selenium. Local e Browserstack

Eu estava usando o estado de teste (recurso, cenário, tags, resultados, etc) nos ganchos para muitas coisas essenciais.

• ter alterações específicas do cenário do URL
• pular testes dinamicamente com base na configuração atual do navegador
• Use o URL específico do cenário para registrar os resultados do teste na pilha de navegadores
• Use nomes de recursos e cenários para gerar nomes de sessão no Browserstack
• Analise as tags para identificar e definir a resolução do navegador específica do cenário

Todos eles foram agrupados em aplicativos para permitir que instâncias simultâneas reduzam o tempo de execução geral.

Por que eles foram descartados?
Eles nunca vão voltar?

@ gd46

O cenário que está sendo executado envolve esse tipo de perfil? Talvez você pudesse fazer com que o cenário salvasse que tipo de perfil está interagindo com o mundo e então você teria uma única etiqueta clara que pedisse a remoção do perfil salvo?

@justusromijn

Para o seu servidor simulado, você poderia mover a configuração baseada em tag para uma etapa que define qual é a configuração? Então você pode parametrizar facilmente.

@Jordyderuijter

Você pode registrar a linha e o uri do cenário (que é realmente único e evita que você tenha que pesquisar o nome do cenário).

@leggebroten

ter alterações específicas do cenário do URL

Você pode usar uma etapa para isso ou usar tags exclusivas

pular testes dinamicamente com base na configuração atual do navegador

Como você estava pulando testes dinamicamente? # 912 adiciona suporte para isso

Use o URL específico do cenário para registrar os resultados do teste na pilha de navegadores

Você pode usar a linha e o uri em vez do nome. Conforme observado antes, a linha e o uri são garantidamente exclusivos, enquanto o nome não. Eu também sugiro analisar o formatador json ou formatador de protocolo de evento para resultados de teste e usar anexos se você precisar adicionar algo.

Use nomes de recursos e cenários para gerar nomes de sessão no Browserstack

Você pode usar a linha + URI

Analise as tags para identificar e definir a resolução do navegador específica do cenário

Você pode usar uma etapa para isso.

De todos esses exemplos, ainda tenho um caso de uso que me convence de que devemos adicionar tags ou nome de volta ao gancho. Ter as tags e o nome parece ter facilitado certas coisas, mas acho que existem outras maneiras de realizá-los que fazem mais sentido para mim

@charlierudolph obrigado pela resposta. Para o mockserver eu já tive uma rápida conversa com alguns colegas de trabalho e usar um "background" compartilhado estava em consideração para uma solução, então sim você pode cruzar aquele da lista.

@charlierudolph Obrigado pela resposta.

Embora suas sugestões de uso de etapas e saída de análise possam funcionar, elas são muito inferiores às versões anteriores, nas quais os retornos de chamada têm acesso ao estado de teste.

0) Inconsistente com o padrão Observer. Os retornos de chamada devem receber os dados de que precisam para o comportamento que estão oferecendo

1) Induz fragilidade extrema . Os testes devem ser confiáveis ​​ou não serão confiáveis. Os números das linhas e os nomes dos arquivos mudam. Simplesmente adicionar ou remover um retorno de carro interromperá os testes.

2) Usar etapas para alterar o estado viola o DRY. Considere o caso frequente de adicionar testes A / B que são marcados com uma etiqueta. A menos que você adicione extensão de linha de comando para executar testes com base nas etapas que eles incluem, os testes exigirão AMBOS a tag e suas etapas de alteração de estado de suporte.

3) Requer que o desenvolvedor faça um trabalho extra. Analisar a saída para encontrar o estado é desnecessário, tedioso, sujeito a erros, vincula os testes aos formatos de saída (acoplamento deficiente) e viola o DRY.

4) Inconsistente com Pepino. Adicionar etapas (uma parte semântica do teste) para alterar o estado do recurso é contrário à intenção de Cucumber de isolar o gravador de teste. Se o comportamento não mudou, o teste não deveria.

5) Não é declarativo. Tags são metadados SOBRE o teste, é semanticamente consistente usá-los para alterar o estado em que o teste será executado. Considerando que as etapas são incorporadas ao teste. Você identifica um conjunto de testes por suas tags ... não pelas etapas que eles usam.

Ah, e na verdade eu não estava "pulando" os testes, estava usando o retorno de chamada (nulo, 'pendente') para evitar a execução do teste. O novo recurso 'pular' é uma solução superior.

@charlierudolph , pensei, outra solução ...
ao construir o objeto World, forneça referência ao objeto Scenario usado para o teste.

Uma vez que o World está disponível como "this" para todos os retornos de chamada, ele alcançaria paridade total com V2 (desde que o retorno de chamada AfterAll recebesse os resultados)

@leggebroten

1. Nunca ouvi que o padrão do observador fosse uma meta de design para pepino.
2. Os nomes dos cenários também são frágeis, pois uma única mudança de caractere também os altera. Eu concordo com a quebra do número do arquivo / linha ao realizar ações que parecem não relacionadas. Eu estava sugerindo o uso em relatórios de resultados e não em testes de execução e, portanto, a parte frágil não tem muito efeito negativo.
3. Using Steps to alter State violates DRY Eu não entendo isso. A tag é usada para selecionar recursos e a etapa é usada para configuração / ações / expectativas. Esses são propósitos diferentes. Temos suporte mínimo para usar a tag para configuração com ganchos com tag, mas ela não foi desenvolvida para lidar com a complexidade.
4. Eu estava apenas sugerindo a análise da saída do formatador para relatórios. Isso não deve estar envolvido na execução de testes.
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 Eu também não entendo. Se você não pode usar etapas para realizar ações e definir o estado, como você está executando os testes?
6. Tags are metadata ABOUT the test, it is semantically consistent to use them to alter the state in which the test will run . Eu discordo sobre isso ser consistente. Tags para mim são apenas para testes de identificação. Há suporte para alteração mínima de estado, mas não para alteração complexa de estado com parâmetros.

Não há mais objeto de cenário no sistema. Não acho que a paridade com a v2 deva ser uma meta. Fico feliz que essa conversa tenha surgido e estou procurando outras soluções, mas não quero voltar ao que tínhamos anteriormente, pois acredito que estava fazendo os usuários confiarem muito mais na implementação do pepino e não em sua interface.

@charlierudolph ,

Obrigado por dedicar seu tempo para discutir este assunto. Eu realmente aprecio o trabalho que você fez para nos fornecer Cucumber-js. Mas, do jeito que está, não posso atualizar para a V3.

Não pretendo ser combativo. Estou apenas preocupado e isso pode aparecer em minhas respostas.

Usando apenas a interface de evento documentada da versão anterior, construí uma estrutura que reduz drasticamente o tempo de execução geral do teste, permitindo que os recursos sejam executados simultaneamente em uma matriz de teste enorme e configurável que inclui sistemas operacionais / versões, navegadores / versões, área de trabalho / Testes móveis e otimizados A / B.

NÃO POSSO usar o Steps. É tarde demais. O tipo de dispositivo, sistema operacional / versão e navegador / versão DEVEM ser determinados antes do início do teste ou cada cenário será forçado a ter uma etapa de "configuração do sistema operacional" e uma etapa de "configuração do navegador". Isso está em conflito direto com os objetivos de Cucumber.

Como alternativa, como mencionei anteriormente, você pode fornecer as informações do cenário (URI do recurso, nome, linha e tags) para o construtor World. Isso é semanticamente consistente com a intenção do objeto World e mais simples de encapsular e estender. Isso não apenas eliminará a maioria dos meus manipuladores de eventos, mas como o "this" do manipulador é o objeto World, é um estado consistente com o padrão do observador.

1. Eu não disse que o Observer Pattern era um objetivo de design da Cucumber. Apenas que Ganchos e Eventos são Observadores e que, como tais, devem receber o estado de que precisam para fazer seu trabalho. Este padrão permite a separação entre a implementação do responsável pela chamada e os manipuladores de eventos.

2. Não tenho dependência dos nomes reais. Mas, como são exclusivos, são o meio de criar o nome de sessão significativo do usuário associado no Browserstack.

3. Ter acesso ao conjunto de Tags durante Antes, me permitiu construir construções reutilizáveis ​​para alterar o Estado (como definir parâmetros de URL do Optimizely) sem modificar o teste (adicionar etapas). Isso significava que havia uma correlação de 1-1 entre os testes que eu queria executar (Tags) e sua configuração. SECO.

4. Você expressou preocupação com o fato de os desenvolvedores estarem se tornando dependentes da implementação, mas sua solução para remover o Estado de observação necessário é tornar o desenvolvedor dependente de outra implementação (formato de arquivo). Como forçar um usuário a fazer um trabalho MUITO mais tedioso, lento e sujeito a erros de análise de arquivos pode ser melhor do que acessar uma propriedade de estado?

5. Obviamente, as etapas estão definindo o estado de teste. Mas um dos objetivos de design do Cucumber era que a pessoa que escrevia os Passos fosse isolada da implementação subjacente. EG testa o comportamento semântico sem se prender aos detalhes subjacentes. Adicionar etapas para alterar os parâmetros de consulta e definir dispositivo / navegador / sistema operacional parece contrário a esse objetivo.

6. Para você, Tags são apenas testes de identificação. Mas Cucumber Wiki tem muitos usos para tags.

7. Organização e agrupamento
8. Filtros (executando conjuntos via linha de comando)
9. Links para documentos relacionados (como sinalizadores Optimizely)
10. Indicar onde está o recurso no processo

Ter acesso às tags durante o retorno de chamada antes me permite garantir o estado apropriado com base na configuração do navegador que está sendo usada para conduzir o teste. O uso de tags torna isso declarativo. Usar etapas ofusca a intenção

As chamadas e parâmetros dos manipuladores de eventos em versões anteriores da interface WERE. Se os desenvolvedores acoplarem seu código com o vazamento de sua implementação, passe um proxy de “cenário” somente leitura para os manipuladores de eventos.

@charlierudolph obrigado pela sua resposta

Os nomes dos cenários também são frágeis, pois uma única mudança de caractere também os altera. Eu concordo com a quebra do número do arquivo / linha ao realizar ações que parecem não relacionadas. Eu estava sugerindo o uso em relatórios de resultados e não em testes de execução e, portanto, a parte frágil não tem muito efeito negativo.

É verdade que os nomes dos cenários também são frágeis, mas é uma maneira muito menos frágil de referenciar cenários do que referenciá-los por arquivo e linha. Estamos usando os nomes dos cenários no registro diário para analisar falhas na execução e ver o que deu errado. Se o registro exibir apenas o arquivo e o número da linha, isso causará muita sobrecarga para rastrear o cenário. Além disso, se alguém fizer alterações no arquivo de feições ou mover o cenário para outro lugar nesse meio tempo, isso ficará ainda mais complicado.

Se o registro exibir apenas o arquivo e o número da linha, isso causará muita sobrecarga para rastrear o cenário.

Como é mais sobrecarga? Você sabe o número do arquivo e da linha e pode ir diretamente para lá. Se você tiver o nome do cenário, terá que pesquisar aquela string a ser levada para aquele arquivo e linha.

Como é mais sobrecarga? Você sabe o número do arquivo e da linha e pode ir diretamente para lá. Se você tiver o nome do cenário, terá que pesquisar aquela string a ser levada para aquele arquivo e linha.

Como eu disse, se o arquivo de feição mudou nesse meio tempo e o cenário não está mais posicionado naquela linha. Especialmente quando estou olhando os registros de uma execução de teste mais antiga (por exemplo, 1 semana atrás). Nesse caso, eu teria que passar pelo git e ver qual cenário estava naquela linha naquele momento.

FWIW, pepino-rubi tem dois pontos de extensão que eu acho que satisfazem o princípio de "coisas fáceis devem ser fáceis, coisas difíceis devem ser possíveis" e podem ser ideias que podem ajudar nesses casos de uso.

Em primeiro lugar, passamos uma instância de RunningTestCase para cada gancho. Este é um objeto de valor imutável que contém todas as informações sobre a origem do Gherkin (cenário / contorno / tags etc.) mais o status do resultado atual do cenário. Ser imutável significa que estamos protegidos de ter que considerar casos em que o usuário pode tentar e mudar coisas conosco, mas também dá a eles transparência sobre o estado atual do jogo.

Em segundo lugar, temos filtros . Os filtros permitem que você manipule o fluxo de casos de teste antes de serem executados. Usamos filtros para, por exemplo, remover casos de teste do fluxo que não correspondem ao padrão de tag especificado na CLI. Os filtros são um recurso de usuário avançado.

HTH

Acabei de perceber que a documentação por trás desse link para filtros é terrível! Desculpa. Não há tempo para consertar agora, mas há mais alguns exemplos aqui: http://www.rubydoc.info/github/cucumber/cucumber-ruby/Cucumber/Filters

Olá @charlierudolph ,

Desculpe, já faz um tempo que não estou acompanhando esta conversa. Você pode elaborar sua declaração:

"O cenário que está sendo executado envolve esse tipo de perfil? Talvez você pudesse fazer com que o cenário salvasse o tipo de perfil que está interagindo com o mundo e, então, você teria uma única etiqueta clara que solicitasse a remoção do perfil salvo?"

Não tenho certeza se estou entendendo.

E eu entendo que talvez haja outras maneiras de obter a mesma solução sem o resultado do teste antigo. Mas, pelo que vi até agora nesta conversa, todas as alternativas parecem mais complexas do que deveriam ser. O resultado do teste antigo tinha muitos dados descritivos sobre o cenário que estava para ser executado e era a única maneira de ter ganchos "parametrizados". O Protractor, tal como está, pelo que vi e tentei, atualmente não oferece suporte à execução de um recurso a partir de um número de linha de cenários. Portanto, o novo resultado do testCase não tem muito que eu ache útil além do status.

Gostaria de ver testCase corresponder ao resultado retornado ao usar getTestCasesFromFileSystem com PickleFilter. Usei isso para fazer um trabalho paralelo interessante para oferecer suporte à filtragem de cenários por tag para passar para o transferidor como fragmentos. As informações retornadas desse resultado são muito mais úteis e acho que seria extremamente útil ter no resultado do testCase.

Resultado de exemplo do PickFilter:

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

Não estou dizendo que precisa ser exatamente igual, mas vejo muito nesse resultado que outros aqui e eu parecemos nos beneficiar.

Se você for interessante em meu exemplo, estou usando-o aqui: https://github.com/gd46/dibellag-automation-framework/blob/master/configuration.js#L91

@charlierudolph É aqui que testCase está sendo definido?

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

Pelo que eu posso dizer, há uma referência a pickle ao longo do lado testCase. Então, por que não retornar mais alguns bits do resultado do pickle para o resultado do testCase?

@ gd46 ok, vamos adicionar pickle ao objeto que é passado para o gancho substituindo sourceLocation. Isso precisa ser atualizado nesta função: https://github.com/cucumber/cucumber-js/blob/master/src/runtime/test_case_runner.js#L153

Olá @charlierudolph , acabei de ver seu comentário. Isso seria bom! Vou tentar dar uma olhada nisso em breve. Eu ficaria feliz em fazer a contribuição.

@charlierudolph Só queria esclarecer a mudança. Estamos de acordo com a diferença de que pickle contém uri sem o número da linha diretamente nele, como sourceLocation faz. E se quem quiser consumir o uri com o número da linha, pode usar os números da linha retornados do objeto pickle? Não vejo nenhum problema com isso, só queria confirmar.

Acho que vamos deixar o objeto de localização de origem como está (em vez de removê-lo) e adicionar o objeto pickle.

Ok, isso funciona para mim também. Então, sou novo na contribuição para o pepino, ainda estou tentando entender a estrutura.

Como você apontou a linha que precisa ser atualizada, acredito que podemos simplesmente adicionar algo assim ao lado de sourceLocation:

pickle: this.testCase.pickle

Então, qualquer pessoa que desejar consumi-lo no gancho pode acessá-lo da seguinte forma:

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

Eu fiz a atualização, mas não estou 100% certo de como atualizar todos os testes relacionados. Você poderia fornecer alguma orientação?

Pude testar a mudança vinculando minha bifurcação às mudanças a um dos meus projetos locais. O resultado completo do testCase será semelhante a este:

{
  "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"
  }
}

Depois de fazer mais alguns testes, percebi que o pickle não contém uri no momento em que temos acesso a ele em test_case_runner. Portanto, acho que não há problema em manter a localização da fonte como está.

É assim que PickleFilter retorna 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"
  }

Então, tudo será o mesmo, menos picles e sem uri.

Abriu um PR para destacar as mudanças até agora. Ainda preciso atualizar os testes.

Trabalhando na atualização de testes. Eu tenho essa coisa configurada para mudar minha versão local do java e percebi que é por isso que eu não fui capaz de executar alguns dos testes de recursos: /.

Este tópico foi bloqueado automaticamente, pois não houve nenhuma atividade recente depois que foi fechado. Abra um novo problema para bugs relacionados.