Cucumber-js: implementar --retry

Criado em 19 jan. 2017  ·  33Comentários  ·  Fonte: cucumber/cucumber-js

seria bom se houvesse um recurso que tentasse novamente o conjunto de testes X vezes e passasse em um teste se esse teste fosse aprovado em qualquer uma das execuções

help wanted

Comentários muito úteis

Com relação à discordância pessoal com esse recurso (este argumento pode ser tão infrutífero quanto tabulações x espaços no mundo da engenharia), se Cucumber como uma especificação de ferramenta está implementando isso, também devemos oferecer suporte na versão JS desta ferramenta.

Ele também está no mundo real, com amplos conjuntos de testes e aplicativos complexos, impossíveis de se defender 100% contra flakeyness e, portanto, torna-se incrivelmente caro. Com certeza, você pode fazer uma jornada de engenharia para melhorá-lo, mas duvido que existam muitas empresas com o luxo de recursos para apoiar esse esforço com um ROI decente.

No mundo real, ser capaz de repetir testes que falharam com a adição de um bom rastreamento para identificar instabilidade para ação pró-ativa é supervalioso.

Agradeceríamos se reconsiderássemos a decisão de encerrar este problema e, conforme declarado antes, estou mais do que feliz em trabalhar nisso com alguma orientação.

Todos 33 comentários

@ericyliu Ele está vindo no pepino 3. Não sei por que o pepino 2 ainda está em RC ... ele está no mercado há 2 anos

@charlierudolph ou qualquer um, se você tiver alguma

Minha abordagem presuntiva seria que, no final da execução de um cenário, podemos dizer se ele falhou ou não e executá-lo novamente (mantendo algum estado para a contagem repetida). Onde posso ligar para isso?

Além disso, eu esperaria no final de todo o processo ser capaz de acessar uma lista de todos os cenários, o número de vezes que eles tentaram novamente e seus status finais para que isso possa ser a) registrado eb) despejado no disco, se desejado .

Fechando porque eu pessoalmente não quero implementar isso, pois discordo disso. Eu não gosto de fornecer um recurso que pode ser usado para lidar com um teste de cintilação em vez de corrigir a causa da cintilação.

👏👏👏

@charlierudolph às vezes é impossível lidar com testes de cintilação. Por exemplo, em nosso ambiente, temos 23 serviços diferentes acessados ​​por nosso aplicativo e, como não somos proprietários desses serviços, qualquer um deles pode estar inativo a qualquer momento. o sinalizador --retry nos permite executar novamente o teste, de forma que uma interrupção temporária do serviço (quando eles reiniciam o serviço) não causa a falha do nosso conjunto de testes.

Com relação à discordância pessoal com esse recurso (este argumento pode ser tão infrutífero quanto tabulações x espaços no mundo da engenharia), se Cucumber como uma especificação de ferramenta está implementando isso, também devemos oferecer suporte na versão JS desta ferramenta.

Ele também está no mundo real, com amplos conjuntos de testes e aplicativos complexos, impossíveis de se defender 100% contra flakeyness e, portanto, torna-se incrivelmente caro. Com certeza, você pode fazer uma jornada de engenharia para melhorá-lo, mas duvido que existam muitas empresas com o luxo de recursos para apoiar esse esforço com um ROI decente.

No mundo real, ser capaz de repetir testes que falharam com a adição de um bom rastreamento para identificar instabilidade para ação pró-ativa é supervalioso.

Agradeceríamos se reconsiderássemos a decisão de encerrar este problema e, conforme declarado antes, estou mais do que feliz em trabalhar nisso com alguma orientação.

Para adicionar a isso cucumber-js already tem rerun funcionalidade que é basicamente apenas uma nova tentativa, mas menos eficiente, uma vez que tem que ser executado como um processo separado (isso fornece, estou entendendo isso corretamente). Tentar novamente é uma solução muito mais agradável.

cc @charlierudolph

Ele também está no mundo real, com amplos conjuntos de testes e aplicativos complexos, impossíveis de se defender 100% contra flakeyness e, portanto, torna-se incrivelmente caro.

Eu absolutamente odeio testes flakey. Em meus projetos atuais, estou tentando deixar de executar qualquer teste flakey no CI e salvá-los para execuções manuais, onde se algo falhar devido à falta de habilidade, você pode executá-lo novamente ou verificá-lo manualmente. Isso depende de encontrar sua fonte de fragilidade e limitar o número de testes necessários para lidar com ela.

Para adicionar a isso, o cucumber-js já tem a funcionalidade de reexecução, que é basicamente apenas uma nova tentativa, mas menos eficiente, pois deve ser executado como um processo separado (isso fornece uma compreensão correta). Tentar novamente é uma solução muito melhor

O Rerun foi criado para que você possa facilmente se concentrar nos testes que precisam ser corrigidos. Sim, você pode usá-lo para tentar novamente apenas os cenários de falha.

Eu concordo 100% com testes escamosos sendo algo a evitar. Dito isso, a fragilidade de um teste geralmente é algo que não está sob o controle da equipe. Aqui está minha situação;

Estou usando Cucumber, Nightwatch, Selenium e Browserstack para executar testes de ponta a ponta em um aplicativo da web. Freqüentemente, um cenário falhará devido à fragilidade inerente do Selenium, Browserstack ou do navegador que estou testando. Interações envolvendo movimentos do mouse são notórias por isso. É raro eu ser capaz de percorrer todos os meus cenários sem pelo menos um punhado ser esquisito.

Não consigo tornar o Selenium, Browserstack ou navegadores menos fragmentados, essa é a natureza das ferramentas com as quais tenho que trabalhar. A solução de que preciso é poder repetir meus cenários algumas vezes se eles falharem.

Acho que devemos reconsiderar isso. Cucumber-Ruby tem agora.

Concordou. Aqui está o código para a implementação Ruby. Pode ser útil para uma implementação de JS. https://github.com/cucumber/cucumber-ruby/pull/920/files

Olá a todos, o recurso 'repetir' já está disponível no Cucumber-JS? Por mais que eu concorde que testes instáveis ​​devem ser corrigidos, a experiência mostra que nem sempre é possível ao trabalhar em grandes projetos com muitas dependências externas envolvidas.
No final do dia, se tal caso de teste instável não pudesse ser coberto pela automação por causa da lógica de nova tentativa ausente, então ele teria que ser testado manualmente de qualquer maneira.
Acredito que o uso da lógica de repetição deve ser deixado como uma escolha para o usuário Cucumber.
Estou ciente do recurso de 'reexecução', mas usá-lo adiciona complexidade extra, pois os testes precisam ser executados novamente separadamente para que o runner do Cucumber faça isso de forma transparente para você.

Olá, @charlierudolph e @aslakhellesoy. Algum progresso com este recurso?

Que eu saiba, ninguém está trabalhando nisso. Se alguém fornecer uma solicitação pull, eu consideraria adicioná-la.

Oi @aslakhellesoy, obrigado por responder tão rapidamente. Isso é algo que realmente precisamos no momento, pois um dos dispositivos que precisamos automatizar é um pouco instável e, nesse caso, não há alternativas realmente práticas para apenas executar novamente um cenário com falha.
Minha ideia é usar uma tag por cenário para especificar a contagem de novas tentativas, mas pelo menos como uma implementação inicial que poderia ser apenas parâmetros de linha de comando.
Tentarei dar uma olhada no código nos próximos dias.

Isso seria bom! Por favor, tente fazer com que ele se comporte da mesma maneira que em Cucumber-Ruby. Se divergir disso, podemos não fundi-lo, pois a consolidação / consistência é algo que buscamos.

Olá @aslakhellesoy , Implementei a funcionalidade de nova tentativa básica como a opção --retry da CLI. Eu testei no trabalho com nosso projeto e funciona bem. Eu precisaria de permissões para empurrar meu branch de trabalho e abrir um PR para discutir a implementação. Me avise, obrigado.

@hurrikam Bom trabalho .. 👏👏👏
Também estou ansioso para usar isso. Estou usando vigia-pepino e eles estão esperando que isso seja consertado no pepino js. Ref # https://github.com/mucsi96/nightwatch-cucumber/issues/213

@charlierudolph poderia ajudar com isso? Não posso enviar meu PR no momento.

@hurrikam você pode criar um fork e enviar seu código para lá e então enviar um PR do fork para este repositório. https://help.github.com/articles/fork-a-repo/

@charlierudolph consulte PR-1114
Conforme mencionado no título, esta é a implementação minimalista (na verdade, muito poucas alterações de código) para fazer o recurso funcionar sem quebrar os formatadores e relatórios existentes.

Passei por algumas conversas antigas no repositório Cucumber Ruby sobre se cada execução de um teste fragmentado deve ser relatada, possivelmente introduzindo um status de resultado 'fragmentado' para as execuções anteriores. Não tenho certeza se isso foi feito e novamente, a desvantagem seria colocar todas as tentativas do mesmo caso de teste nos logs.

Vamos discutir isso.

@hurrikam minha equipe fez uma bifurcação do PR para que possamos obter essa funcionalidade. Está funcionando muito bem até agora. Espero que você consiga mesclá-lo em breve, pois a bandeira é uma grande ajuda!

@Nick-Lucas Isso é incrível - você tem isso?

@thomaswmanion sim, estamos usando ativamente o recurso. Temos um back-end que às vezes pode ficar um pouco sobrecarregado ao limpar as filas de trabalho, então tem sido um salva-vidas.

Para quem deseja usar o PR, você pode apontar seu package.json para o meu fork (ou garfo-lo de mim):

  "dependencies": {
    "cucumber": "https://github.com/Nick-Lucas/cucumber-js.git#feature/issue-727-retry",
  },

Cucumber é pré-construído para que possa ser instalado apenas em node_modules. Nem é preciso dizer que definitivamente não há garantia ou suporte, pois o recurso ainda nem é pré-alfa

EDITAR:

Já deixei minha empresa e entreguei o fork ao github: https://github.com/wonderbill/cucumber-js.git#feature/issue -727-retry

Agradável!!!! Obrigado @ Nick-Lucas - aprecie a compreensão de que os ambientes dos sistemas podem ser instáveis ​​por natureza!

Isso precisa ser mesclado com o Mestre, não é fechado.

@thomaswmanion sim, estamos usando ativamente o recurso. Temos um back-end que às vezes pode ficar um pouco sobrecarregado ao limpar as filas de trabalho, então tem sido um salva-vidas.

Para quem deseja usar o PR, você pode apontar seu package.json para o meu fork (ou garfo-lo de mim):

  "dependencies": {
    "cucumber": "https://github.com/Nick-Lucas/cucumber-js.git#feature/issue-727-retry",
  },

Cucumber é pré-construído para que possa ser instalado apenas em node_modules. Nem é preciso dizer que _definidamente não há garantia ou suporte_, pois o recurso ainda nem é pré-alfa

EDITAR:

Já deixei minha empresa e entreguei o fork ao github: https://github.com/wonderbill/cucumber-js.git#feature/issue -727-retry

Como posso executar o recurso de repetição durante a execução de testes?

@ricardgarcia basta usar a opção --retry consulte https://github.com/owncloud/phoenix/pull/1207/files
Estamos usando o branch do meu PR aqui https://github.com/cucumber/cucumber-js/pull/1205 até que seja fundido, espero que um dia

Olá @ individual-it, muito obrigado pela resposta. Deve funcionar se eu estiver usando o webdriverIO para executar meus testes no cucumber-js?
Eu tentei o comando "--retry 1", mas nenhuma nova tentativa está sendo feita.

@ricardgarcia Conforme descrito em https://github.com/cucumber/cucumber-js/pull/1205 , para usar esta função você pode usar

"cucumber": "cucumber/cucumber-js#issue-727-retry"

já que as alterações ainda não foram mescladas no repositório principal do pepino.

Sim @ jain-neeeraj usei esta versão no package.json e não funcionou, mas como mencionei estou executando testes usando pepino no webdriverIO, então o seguinte framework "wdio-cucumber-framework". Deve funcionar de alguma forma? Como executo os testes para tentar novamente se usar o framework cucumber-js?

@ricardgarcia permite colaborar em gitter https://gitter.im/cucumber/cucumber-js , devo poder ajudá-lo a resolver esse problema.

@charlierudolph alguma chance de ser mesclado com o master?

Esta página foi útil?
0 / 5 - 0 avaliações