Webdriverio: BUG: webdriverio [v5] não para a execução no caso de uma exceção ser lançada no gancho before ()

o teste não está sendo executado para mim se eu tiver antes de bloquear como este

    before: function (capabilities, specs) {
        throw new Error('oops')
    }

O problema é que antes do bloco ser executado antes de cada arquivo de teste, é por isso que você está vendo esse comportamento

se você mover seu bloco de código para o bloco onPrepare, ele funcionará conforme o esperado, @erinev

@mgrybyk obrigado pela resposta rápida. Infelizmente, não podemos usar o gancho onPrepare () porque ele não tem o contexto browser e precisamos fazer o login da IU antes de todos os testes.

código:

onPrepare(config) {
    browser.url('https://google.com');
},

resulta em: ReferenceError: browser is not defined

porque o hook before () é executado antes de cada novo arquivo de especificação (não caso de teste ou descrição, mas arquivo de especificação)
nós contornamos desta forma: temos apenas um arquivo spec all-test-cases.spec.js e dentro dele exigimos outros arquivos (== descreve). Portanto, temos um único login antes de todos os testes

mas não queremos usar o hook beforeAll () apropriado que teria o navegador configurado (como o before () fez) para remover aquele hack, que requer outros arquivos de casos em um.

se isso é algo que deve ser executado uma vez que você pode seguir a abordagem mencionada aqui https://github.com/webdriverio/webdriverio/issues/3747

@mgrybyk se bem entendi # 3747 caso não é o mesmo que temos.

Caso você tenha fornecido, foi necessário realizar o DOWNLOAD DOS ARQUIVOS (que não requer ações do navegador) antes de todos os testes
em nosso caso, precisamos realizar o login de uma única vez (antes de todos os testes) porque registrar várias vezes para cada arquivo de especificação tornaria os testes muito mais longos e nossa empresa tem no máximo X logins por política de 1 minuto, então se tivéssemos mais de 10 arquivos de especificação, violar esse limite e precisaríamos codificar algum tipo de navegador que dorme para não violar esse limite de login.

então, se eu entendi o problema que você forneceu corretamente, esta solução com algum tipo de etapa de gancho extra não funcionaria para nós, porque precisamos usar a mesma instância do navegador.

o fluxo de trabalho é parecido com este:

1) gancho onPrepare (criar pasta de captura de tela com falha)
2) antes de todas as etapas -> faça login em nosso site (navegador.url ('/ login'); nome de usuário.setValue, senha.setValue, loginButton.click)
3) execute cada arquivo de especificação (usando a mesma sessão de login criada na etapa 2.)

Espero ter explicado claramente o que queremos alcançar, se não, posso tentar elaborar mais sobre nosso caso.

@mgrybyk, nós nos

Você concorda que é um bug e deve ser corrigido?
(porque, em minha opinião, a execução deve ser interrompida no caso de uma exceção ser lançada e usamos a opção Bail: 1 para as opções mocha e configuração do wdio, portanto, deve sair no primeiro erro (e não continuar a execução)).

Este é um comportamento conhecido e não exatamente um bug. Os ganchos WDIO são executados em uma fibra / processo diferente e realmente não reportam ao thread principal.

Conversei com @ christian-bromann sobre isso há vários meses e acredito que seja realmente intencional.

É difícil justificar um gancho travando toda a sua corrida. Você poderia estar executando 10 testes em paralelo, mas apenas um deles gera um erro ... por que aquele teste deveria quebrar todos os 10?

Se você precisar fazer o mocha-bail funcionar, use os ganchos do mocha;) (eles encerrarão o teste conforme o esperado).

@abjerstedt se você disser que os ganchos não reportam ao thread principal, quais são os ganchos que você tem em mente exatamente? (apenas berfore () gancho?) porque se eu lançar um erro no gancho onPrepare () a execução do gancho será interrompida:

onPrepare(config) {
    // On Prepare logic here (create folder for failed screenshots)

    throw Error('!!!!!!!!!!!!!!!!!!!! Some error is thrown in onPrepare() hook !!!!!!!!!!!!!!!!!!!!'); // TODO: why thrown exceptions (waitUntil, etc) doesn't stop execution ?
  },

você poderia elaborar mais sobre a lógica de ganchos por que alguns relatórios voltam para o thread principal e outros não?

quais outros ganchos não reportam ao tópico principal?

Também é possível introduzir o hook beforeAll () que é disparado antes de todos os testes, mas tem o navegador iniciado (como o hook before ()) e reportaria de volta ao thread principal como hook onPrepare ()?

Os ganchos definidos na configuração são ganchos do webdriverio.
Ganchos definidos em seus arquivos de especificação são ganchos mocha.

Se uma exceção for lançada no gancho do webdriverio, o gancho será encerrado, mas o teste continuará.
Se uma exceção for lançada no gancho do mocha, o teste será encerrado corretamente.

@ christian-bromann como eu penso sobre isso, ainda temos alguns ganchos que eu acho que devem borbulhar exceções (como depois / antes do comando).

@abjerstedt aqui é uma prova de que o gancho wdio onPrepare () dentro da configuração interrompe a execução do teste no caso de ocorrer uma exceção. Ramificação separada é criada para reproduzir o problema. Resultado:

@erinev , você tem pensado em usar cookies? Você pode fazer o login uma vez no gancho do script, pegar cookies / token de qualquer coisa e em seus testes usando-o. Além disso, há outras maneiras de lidar com sua disposição sem tocar em nenhum gancho do wdio ou do mocha. Se eu encontrar um determinado link, irei postar.

A principal questão para seus desenvolvedores é como posso fazer o login sem tocar na interface do usuário.

onPrepare é uma espécie de exceção, este gancho é chamado antes que o processo wdio realmente comece.

@CrispusDH você não acha que é uma solução alternativa? se tivermos uma estrutura, por que precisamos contornar e executar o login usando API e definindo cookies e assim por diante. Usuários reais da interface do usuário não realizam login através da API, eles fazem login usando a interface do usuário, então os testes devem replicar isso, se possível, em minha opinião. O login não é o único caso de uso que seria conveniente ter em um gancho antes de cada / todos os testes.

@abjerstedt , @mgrybyk
Vocês estão me dizendo como ele está implementado agora, mas vocês não sentem pelo menos uma pequena necessidade, como desenvolvedores, de pensar um pouco fora da caixa? estou tentando desafiar a pensar que a abordagem atual é a melhor abordagem? (talvez pudesse melhorar de alguma forma?)

eu não pediria alguns ganchos de teste beforeAll se outros frameworks não tivessem tal implementação (por exemplo: o transferidor angulars tem o gancho onPrepare que tem o navegador inicializado e é executado antes de todos os testes, não antes de cada arquivo de especificação e lida com exceções corretamente.)

você poderia fornecer um exemplo além da captura de tela após o teste falhado, onde ganchos que não tratam de exceções podem ser utilizados totalmente? porque qualquer código pode lançar uma exceção e se a execução do código continuar, isso significa que terá algum efeito colateral no próprio teste se o gancho falhar (porque você faz algo em um gancho para se preparar para os próprios testes, portanto, se não estiver preparado, o teste falha, mas não porque Assert falha, mas porque o gancho falhou e tais falhas inesperadas causam perda de confiança nos próprios testes automatizados)

não sou um grande guru em testes de javascript e selênio e minha opinião pode estar totalmente errada, claro, mas estou interessado na sua opinião de outro ponto de vista (não como é agora, mas como poderia ser e se deveria ser como está agora, por quê?).

A propósito, eu gosto mais do webdriver-io do que transferidor por 2 razões principais: modo de sincronização e seletores jquery (torna o código mais limpo sem precisar esperar tudo e os seletores podem ser testados no navegador), mas o sistema de ganchos é implementado melhor no transferidor, na minha opinião e eu gostaria de iniciar a mudança aqui, para que não haja nenhuma ideia de pensar em outra estrutura além do webriver-io

@erinev concordo totalmente com você. É por isso que devemos testar o login. Outros testes já devem estar logados pelo usuário usando cookie, token na URL, etc., pois isso economizaria tempo.

Olá @ christian-bromann,

o que você acha sobre a abordagem atual de como os ganchos wdio são implementados?
poderia ser mais útil adicionando manipulação de exceção e introduzindo hook beforeAll ()?
(não faria sentido? talvez não seja fácil de fazer, mas estou perguntando sobre a possibilidade no futuro de mudar o atual, na minha opinião limitante, abordagem de como os ganchos são montados agora?)

O motivo pelo qual não lidamos com erros em ganchos é que eu queria evitar problemas e bugs de serviços de terceiros para arruinar as experiências. Cada vez que alguém apresenta esse problema em um serviço de terceiros que não somos de nossa propriedade, isso fará com que as pessoas levantem problemas aqui e, mesmo se formos capazes de corrigi-los, não seremos capazes de lançar a correção do bug. Quero ser mais cuidadoso aqui para garantir que os testes das pessoas sejam executados de maneira estável.

Não recomendo colocar algo que pertence a um teste em um gancho de wdio. Algo que é crítico para o seu teste deve pertencer ao teste, não ao gancho. Se você precisar entrar em algum lugar para testar coisas, essa parte do login ainda deve fazer parte do teste. Existem maneiras de encapsular isso em objetos de página.

Estou feliz por ter uma discussão sobre isso. Eu posso estar errado sobre essa abordagem também.

@erinev seria bom se você criasse um repositório de demonstração com um exemplo de qual arquitetura você tem nos testes e mostrasse suas preocupações.

@ christian-bromann obrigado pelo esclarecimento porque é feito desta forma.

@CrispusDH ok, vou preparar o repo de demonstração e adicionar comentários com o raciocínio para a nossa abordagem e podemos discutir nesse repo então.

para nós, não é um grande bloqueador que os ganchos não lidam com exceção porque usamos a opção de fiança para que apenas um teste falhe e será fácil detectá-lo a partir de capturas de tela que o login falhou. Então, estou encerrando este problema.

Vamos passar a dissuasão para https://github.com/webdriverio/webdriverio/issues/3923 , porque para nós o login único é mais importante do que o tratamento de erros (podemos viver sem ele e está claro que você fez dessa forma intencionalmente (do passado experiência)

Vou criar um repositório com nosso caso de uso desejado ainda. Na edição acima (# 3923), adicionei contexto adicional no caso de uso de login único.

Pessoal, e se introduzirmos o objeto GlobalContext compartilhado por todos os processos?

Acho que deve ser útil e ajudar a lidar com questões como esta.

Acho que deve ser útil e ajudar a lidar com questões como esta.

Como?

Ex, configuração de sinalizador global para controlar o fluxo.
Isso permitirá realizar alguma ação apenas uma vez. Compartilhe algum objeto em vários arquivos de especificações

@mgrybyk qual é o caso de uso exatamente?

o gancho wdio "antes" permite que você execute um lote de coisas UMA VEZ antes de qualquer instância. Não importa quantos testes você execute, ele não será executado novamente.

O gancho wdio beforeSuite / beforeAll mocha / pepino / jasmim permite que você execute o mesmo gancho uma vez antes de cada suíte.

O problema não é que o before hook é realmente executado para cada arquivo de especificação em vez de ser executado apenas uma vez? Before is beforeSpec.

As pessoas o estão usando porque é o primeiro gancho em que o objeto do navegador está disponível.

O que estamos perdendo é antes do gancho com o objeto do navegador disponível que executa apenas uma vez.
Para contornar isso, podemos introduzir algum objeto global onde é possível definir algum sinalizador personalizado para identidade se alguma ação foi executada ou não.

if (! globalContext.doOnce) {
...
globalContext.doOnce = true
}

@mgrybyk exatamente o que está faltando para nosso caso de uso.

Para este caso de uso, temos onPrepare / onComplete, não?

Sim, mas o objeto do navegador não está disponível lá.
Adicionar um gancho como beforeAll (ou adicionar globalContext compartilhado onde podemos definir alguma sinalização e usá-lo antes do gancho) em combinação com a capacidade de compartilhar a sessão do navegador entre os arquivos de especificação deve ajudar.

Se você deseja ter acesso ao objeto do navegador, você precisa iniciar com o gancho before mas se quiser executá-lo em paralelo, você terá problemas. Como você deseja fornecer um gancho que compartilhe uma sessão do navegador. O design do WebdriverIO impõe novas sessões para cada arquivo de especificação para garantir que os testes sejam independentes uns dos outros.

nossos arquivos de teste são independentes uns dos outros, mas temos casos de uso para executar esses testes na mesma sessão (teste o fluxo de trabalho completo do usuário real). Usaremos uma solução alternativa com um único arquivo de especificações para testes completos de fluxo de trabalho em uma única sessão.

Obrigado por informações sobre como o webdriver-io foi projetado.

Como você deseja fornecer um gancho que compartilhe uma sessão do navegador.

Gerar instância por sessão ou limitar instâncias a 1 caso a abordagem de instância compartilhada seja usada

nossos arquivos de teste são independentes uns dos outros, mas temos casos de uso para executar esses testes na mesma sessão (teste o fluxo de trabalho completo do usuário real). Usaremos uma solução alternativa com um único arquivo de especificações para testes completos de fluxo de trabalho em uma única sessão.

Obrigado por informações sobre como o webdriver-io foi projetado.

Basta usar abstração. Pegue blocos de código repetível e coloque-os em funções importáveis. O Mocha (e eu acredito que o Jasmine) permite que você importe e invoque funções que chamam os blocos describe () ou it (). Você pode literalmente fazer a importação de um arquivo de especificações e invocar uma seção de código:

importe 'loginTest' de 'LoginTest'

loginTest ()

^ ---- você poderia então fazer todos os seus arquivos de especificação chamarem este bloco de código

@abjerstedt como isso é diferente do atual antes do gancho? (podemos facilmente alcançar a mesma funcionalidade com o before hook, se todos os arquivos spec incluirão o teste de login, ainda será um login por arquivo == igual ao before hook contendo a funcionalidade de login). ou você tinha algo diferente em mente?