Cucumber-js: o resultado do cenário não foi passado para os ganchos antes / depois

Fui mordido por isso. Nossa atualização para 3 no Pepino Pro está em espera por causa disso.

Https://github.com/cucumber/cucumber-js/blob/fbff6b0fae54d2e341ee247addc60a9f05753f1d/src/runtime/test_case_runner.js#L109 é o culpado?

Que parte disso é necessária exatamente? Você usa apenas os predicados de status? Essa parece ser a única coisa usada nos documentos que cercam este

Atualmente usamos scenarioResult.status , scenarioResult.scenario.uri e scenarioResult.scenario.line .

@jbpros seu caso de uso segue os exemplos que temos atualmente em torno disso (salvar uma captura de tela quando um cenário falha)? Sempre achei muito estranho que o cenário tivesse sido passado em ganchos e gostaria de encontrar uma maneira diferente de lidar com isso.

Atualmente, estou pensando em adicionar uma nova função de código de suporte: onFailedTestStep que permite definir uma função a ser chamada com uma falha de etapa de teste. Ele seria chamado com o mesmo argumento mundial da etapa com falha e, portanto, você poderia anexar uma imagem ou algo parecido. Poderíamos criar um módulo dedicado para analisar anexos fora do formatador de protocolo de evento e copiá-los em uma pasta.

Como um usuário consertador, eu gostaria que qualquer função / manipulador / objeto tivesse o máximo de contexto possível. Mesmo sem algo grandioso como toda a árvore de execução de passado e futuro (https://github.com/cucumber/cucumber-js/issues/875), seria extremamente útil saber qual é a etapa atual e o cenário para cada falha.
Por exemplo, isso me permite controlar os procedimentos de rollback de acordo com as tags, ou simplesmente ver quais outras etapas foram executadas antes da falha.

Recomendo que você considere passá-los para onFailedTestStep , se essa for a solução que você deseja.

Os Hook Docs também precisam ser atualizados - o link do primeiro parágrafo para ScenarioResult é 404.

Em vez de onFailedTestStep , por que não definir um gancho chamado AfterStep ? Cucumber-Ruby tem isso há muito tempo e, como você sabe, a consistência é importante.

@aslakhellesoy Quero me concentrar no caso de uso e ter certeza de que estamos resolvendo da maneira certa.

A consistência é importante, mas isso não significa que devemos copiar tudo apenas porque existe em outro lugar. Devemos estar evoluindo à medida que determinamos as melhores maneiras de lidar com as coisas

Você, @mattwynne ou alguém da equipe ruby ​​podem esclarecer para que o AfterStep foi construído e para que é usado?

Não sou da equipe ruby, então não sei para que AfterStep foi criado, mas pessoalmente uso AfterStep para fazer várias operações. aqui estão alguns exemplos:

1. Faça uma captura de tela e registre o log do navegador em cenários de falha
2. Faça registros adicionais para algum projeto, independentemente de ter falhado ou não
3. Limpar

Para nós, precisaremos que o cenário e o resultado sejam passados ​​para AfterStep qualquer maneira para fazer um registro adicional. Tenho certeza de que existem outros casos de uso que precisam deles em AfterStep , também, que nem sequer consideramos.

Isso significa que se houvesse algo como onFailedTestStep , teremos mais de uma maneira de conseguir a mesma coisa: uma para usar AfterStep e outra para usar onFailedTestStep .

Isso também pode causar inconsistência dentro dos projetos, dependendo de quem implementou o gancho; alguns podem usar AfterStep enquanto outros podem usar onFailedTestStep . Eu não acho que nenhum desses seja desejável.

@charlierudolph

Eu quero entender de onde você está vindo. Você se importaria de explicar por que você pensa o seguinte?

Sempre pensei que era muito estranho que o cenário fosse passado para ganchos

Nunca gostei muito da mistura dos dois paradigmas. Os ganchos Antes / Depois estão relacionados à configuração / desmontagem com a execução efetiva dos testes. Usá-lo também para relatórios parece algo que deve ser cuidado separadamente

Faça uma captura de tela e registre o log do navegador em cenários de falha

Se você estiver fazendo isso no AfterStep, isso está sendo feito para etapas com falha, não para cenários com falha. É para isso que todos os exemplos no repo estão usando o objeto de cenário e é por isso que quero fazer um novo gancho para este caso de uso específico. Eu não ouvi nenhum outro caso de uso atraente.

Faça registros adicionais para algum projeto, independentemente de ter falhado ou não

Que tipo de registro adicional você faz?

Limpar

O que há para limpar após uma etapa?

Para nós, precisaremos que o cenário e o resultado sejam passados ​​para o AfterStep de qualquer maneira para fazer log adicional. Tenho certeza de que há outros casos de uso que precisam deles no AfterStep também, que ainda nem consideramos.

Estou tentando coletar esses casos de uso. Às vezes, as pessoas podem estar usando quando há outras maneiras de fazer isso ou como uma solução alternativa para algo para o qual poderíamos oferecer um suporte melhor.

Isso significa que se houvesse algo como onFailedTestStep, teríamos mais de uma maneira de conseguir a mesma coisa: uma para usar o AfterStep e a outra para usar o onFailedTestStep.

Cucumber-js atualmente não tem AfterStep e não planejo implementar ambos.

Estou tentando obter suporte para pepino 3 na estrutura do transferidor-pepino e poderia realmente usar um AfterStep . Eu percebo que uma biblioteca que une duas outras bibliotecas não é o mais comum dos casos de uso, mas a tornaria muito mais simples. Estou tentando descobrir como fazer isso com o novo material de protocolo de evento, mas não estou obtendo nenhum contexto de recurso / cenário / etapa em nenhum dos eventos *-finished . Usamos os nomes, uris e números de linha do recurso, cenário e etapas para relatar ao transferidor e dar às integrações IDE (Intellij) algo para mostrar e navegar em sua árvore. Meus $ 0,02 de qualquer maneira.

Apenas para mencionar que todas as funcionalidades discutidas (e muito mais) podem ser realizadas com setDefinitionFunctionWrapper .
Você pode agrupar todas as etapas com ações pré / pós, que não apenas permitem que você reaja às entradas e saídas de uma etapa, mas até mesmo modifique-as.

Então, por exemplo, eu o uso para implementar uma etapa "A próxima etapa deve falhar com o erro XYZ", que me permite implementar rapidamente verificações negativas profundas e simulações de erro sem implementar etapas negativas duplicadas ou tratamento de erro invertível especial em cada etapa .

Acho que não há nada que um gancho AfterStep possa fazer que setDefinitionFunctionWrapper não possa.

Alguma atualização sobre isso? Tentando atualizar de 2.0.0 para 3.0.0 no trabalho e ainda ficando indefinido para sceneryResult

@ paul-phillips-ark sim, veja # 905. Se você quiser ajudar a avançar, você pode ramificar e enviar um novo pr que aborda os comentários de @charlierudolph .

Quando eu console.log (sceneryResult), ainda estou ficando indefinido nas funções Antes e Depois? Estou esquecendo de algo? Desculpas se o comentário acima soa denso.

Meus casos de uso atualmente são os seguintes:

Antes de cada cenário, solicito acessórios que preencham meu banco de dados para teste. Cada recurso tem seu próprio conjunto de acessórios necessários para isso. O caminho do dispositivo de fixação no servidor repete o caminho do recurso, então eu preciso da opção uri também:

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

No gancho After tantos de nós, eu faço uma captura de tela:

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

@charlierudolph você poderia cortar uma versão com solicitação pull # 905 como solução provisória? permite-nos terminar a transição de v2 para v3 - que atualmente está travada devido a esta regressão / mudança. sua refatoração proposta pode ir para outra solicitação pull.

Existem alguns problemas para o # 905, mas tentarei consertá-lo e fazer um lançamento neste fim de semana.

Este tópico foi bloqueado automaticamente, pois não houve nenhuma atividade recente após seu encerramento. Abra um novo problema para bugs relacionados.