@christian-bromann Quais são alguns dos recursos propostos até agora?

@KenzoM Eu não passei por todos os tickets com minha triagem, mas fiz um marco de v5

@christian-bromann
Eu gostaria de ver este pedido se tornar realidade:
https://github.com/webdriverio/webdriverio/issues/1695

+1

Eu adoraria ver a repetição do teste para Jasmine....

@ mkj28 você viu http://webdriver.io/guide/testrunner/retry.html#Rerun -single-tests-in-Jasmine-or-Mocha

Eu amaria ter
https://github.com/webdriverio/webdriverio/issues/2185
https://github.com/webdriverio/webdriverio/issues/1890

@ mkj28 o que você quer dizer com tentar novamente exatamente? qual API você gostaria de ver? Ou link para um problema existente

Ei Cris, eu tentei isso há algum tempo e ainda era um problema para mim: https://github.com/webdriverio/wdio-cucumber-framework/issues/36

Podemos também integrar o axe-core para a Acessibilidade na Web?
@klamping foi incrível para nos mostrar a configuração básica. Seria legal se o V5 vier com ele.

https://www.youtube.com/watch?v=6gwtqYCxNwQ&t=26s

@KenzoM bem o axe-core já funciona com o WebdriverIO, mas não é simplificado para um comando. Afinal isso seria um plugin e nada que seria integrado ao núcleo do WebdriverIO.

@KenzoM fyi, alguém tentou montar um serviço Axe aqui: https://github.com/cerner/terra-toolkit/blob/master/src/wdio/services/AxeService.js

Uma ideia que tenho é solicitar credenciais Sauce/BS/TB se elas não forem encontradas (mas solicitadas na configuração). No momento, quando você inicializa a configuração pela primeira vez, ela solicita suas credenciais. Mas uma vez definido, ele assume que já está lá.

O problema é que, se alguém novo se juntar ao projeto, eles precisam configurar manualmente essas variáveis ​​Env. Não é uma tarefa grande, mas pode ser confusa para novatos e aqueles menos familiarizados com variáveis ​​de ambiente.

Em vez disso, faça com que o WDIO faça uma detecção se SL/BS/TB estiver sendo usado (talvez se o serviço estiver definido?), e solicite (e defina) essas variáveis ​​de ambiente para o usuário.

Existem muitos comandos que têm variantes. Você pode encontrá-los com o padrão /não correspondeu a um comando conhecido/. Não sei por que, mas por algum motivo a prioridade é dada a comandos que não são compatíveis com W3C.

Por exemplo browser.execute e browser.windowHandlePosition sempre recebem duas solicitações no geckodriver autônomo.

Talvez faça sentido tentar os comandos W3C primeiro? Ou fazer um parâmetro talvez.

Talvez faça sentido tentar os comandos W3C primeiro?

Quando lançarmos a v5, a maioria dos drivers provavelmente já fala a última especificação W3C e podemos mudar a ordem. Bom ponto! No momento, acho que isso afeta apenas os testes de FF.

Que tal ter o Suporte Jest?
https://github.com/webdriverio/webdriverio/issues/2052

Eu gostaria de ver um suporte ainda melhor para objetos de página / encadeamento.
Atualmente alguns métodos não funcionam como esperado quando acoplados a objetos/cadeias de página como o comando scroll que fica claro nos seguintes casos de teste que criei:

    it('should scroll to specific element while chained', async function () {
        await this.client.windowHandleSize({width: 100, height: 100})
        await this.client.element('.box').scroll()

        const scrollPos = await this.client.execute(() => {
            return {
                x: $(document).scrollLeft(),
                y: $(document).scrollTop()
            }
        })

        scrollPos.value.x.should.be.approximately(15, 15)
        scrollPos.value.y.should.be.approximately(262, 40)
    })

    it('should scroll to specific element with offset while chained', async function () {
        await this.client.windowHandleSize({width: 100, height: 100})
        await this.client.element('.box').scroll(-10, -22)

        const scrollPos = await this.client.execute(() => {
            return {
                x: $(document).scrollLeft(),
                y: $(document).scrollTop()
            }
        })

        scrollPos.value.x.should.be.approximately(5, 15)
        scrollPos.value.y.should.be.approximately(240, 40)
    })

@erwinheitzman não sabe por que a rolagem é importante em seu teste, geralmente não é. Você pode explicar com mais detalhes qual a diferença entre:

await this.client.element('.box').scroll()

e

await this.client.element('.box').scroll(-10, -22)

é e que falta de apoio você vê aqui?

@christian-bromann Concordo que geralmente não é necessário, mas quando estava com problemas para clicar em um elemento específico há alguns dias, tentei rolar antes de clicar.
Quando tentei PageObject.myGetter.scroll() fiquei surpreso que não funcionou da mesma forma que browser.scroll('my-selector').

A diferença entre os exemplos fornecidos é que um não usa nenhum deslocamento e o outro usa, eu estava tentando ver se poderia corrigir o comportamento do método de rolagem, então adicionei esses testes localmente (nunca consegui funcionar, pois um teste manteve falhando).
EDIT: eu notei que você mudou esse teste, então talvez eu tenha consertado
https://github.com/webdriverio/webdriverio/commit/a799a8460b9b5941994409a502cd84cb60a630e9

O suporte que estava faltando é poder usar MyPageObject.myGetter.scroll() com e sem deslocamentos e com e sem seletor.

Não é uma obrigação absoluta, mas acho que seria bom se pudéssemos apoiá-lo. Talvez seja uma boa adição para uma versão mais adiante.

Talvez seja uma boa adição para uma versão mais adiante.

Provavelmente. Eu acho que é importante fornecer um comportamento consistente. O problema é conhecido e semelhante ao #1879. Eu acho que isso será definitivamente corrigido nas próximas iterações.

No entanto, problemas com cliques são comuns. O motivo geralmente é porque há outro elemento (por exemplo, com position:fixed localizado no topo do elemento de destino. Prefiro remover esse elemento em vez de usar scoll. Em última análise, o comando de rolagem será removido.

Eu adoraria ver o #2357 ser implementado :)

o que você quer dizer com repetir exatamente

@ORESoftware atualmente, você só pode executar novamente o bloco ou gancho de teste, não o teste inteiro ou o conjunto de testes. Então, o que quero dizer é ter um número global (digamos em wdio.conf.js ) definido de tentativas para todo o teste. A prioridade mais baixa (mas ainda melhor do que nada) seria executar novamente o conjunto inteiro.

Atualmente, a única maneira de conseguir isso com Jasmine que posso ver é escrever meu próprio repórter ou analisar os resultados dos testes sozinho e fazer outra passagem do webdriver.io para os conjuntos de testes específicos.

Acho que alguns perfis de desempenho em torno da execução de testes em paralelo seriam interessantes. E se poderia haver algum ganho lá

https://github.com/webdriverio/webdriverio/issues/1643

Além disso, se estou tentando corrigir um teste esquisito, gosto de executá-lo novamente x vezes para ver se ele passa de forma consistente. Atualmente, eu apenas envolvo o teste em um loop for, mas não tenho certeza de como seria uma boa sintaxe, talvez semelhante à implementação wdio de repetir testes flaky

@christian-bromann você já pensou em como o wdio poderia usar funções lambda para executar testes?

funções lambda para executar testes?

@kevinmcdonnell não tenho certeza do que você quer dizer com funções lambda. Você está falando sobre AWS lambda? Nesse caso, acho que é uma abordagem interessante executar ainda mais testes em paralelo.

Sim, tem havido muitos projetos surgindo em torno do chrome (https://www.npmjs.com/package/@serverless-chrome/lambda) e testes em lambda.

Este parece um projeto muito interessante, por exemplo https://github.com/graphcool/chromeless#api -documentation

Clay Smith aqui obteve testes de nós com o webdriver trabalhando em um lambda https://medium.com/clog/running-selenium-and-headless-chrome-on-aws-lambda-fb350458e4df

executar testes em lambda é um divisor de águas para executar testes rapidamente. Uma suíte de 20 minutos pode ser tão lenta quanto o teste mais lento

Ei pessoal, o que é um ETA para a versão v5?

@dguzmanSM Eu trabalho nisso no meu tempo livre, então sempre que eu tiver tempo para isso, provavelmente não este ano, por favor, siga-nos no Twitter e não peça ETAs

@christian-bromann desculpe cara, não queria parecer insistente, eu sei que é um projeto de código aberto, e é INCRÍVEL!, acabei de falar sobre WebdriverIO no primeiro MeetUp do grupo TestingCR, aqui na Costa Rica. As pessoas adoram!

apenas uma atualização na minha ideia lambda. Parece que isso será mais facilmente alcançado usando o AWS Fargate (https://aws.amazon.com/fargate/ é um novo produto ainda em beta).

A ideia é que nosso workflow jenkins crie um container que tenha todas as dependências de teste e um checkout do código. Se nosso conjunto de testes tiver 100 arquivos de especificação, usamos fargate para executar 100 contêineres, cada um executando 1 arquivo de especificação. Precisaríamos de alguma maneira de orquestrar a comunicação com fargate e a divisão de arquivos de especificação, acho que isso poderia ser alcançado por um plugin wdio (precisa procurar como criar um)

@kevinmcdonnell, esta é uma ótima ideia e provavelmente será enviada no novo executor de testes da v5. Acho que a integração mais simples é verificar uma chave AWS ou GCE e executá-las automaticamente como função lambda, se existirem na configuração.

Observe que este é um novo produto AWS fargate não AWS lambda. O Lambda tem limitação no tamanho do que você pode passar para ele (o que pode ser feito para funcionar, mas pode ser mais difícil e menos versátil), enquanto o fargate apenas executa um contêiner que você construiu para que possa facilmente ter dependências como chrome/firefox , escolha do SO, um checkout do seu código etc

Imagino que usaríamos o nó AWS SDK para conversar com o AWS fargate. Isso pode ser por meio de chaves ou função do IAM. Gostaríamos de uma opção para ambos, pois se executássemos isso em nossa instância do Jenkins, gostaríamos de usar o IAM por motivos de segurança.

Acho que haveria uma etapa de construção relacionada à construção do contêiner. Dado que temos muitos projetos, teríamos um contêiner padrão definido e, em seguida, a etapa de compilação copiaria o código para um determinado projeto e enviaria o contêiner gerado para um registro.

Portanto, a configuração do wdio também precisaria de configuração para o registro de contêiner e o contêiner. Então fargate executaria o comando no container que contém as dependências e um checkout do código.

obviamente, o wdio gostaria de uma implementação o mais genérica possível, ao mesmo tempo em que suporta casos de uso comuns. espero que nas próximas semanas eu possa tentar fargate e especificar como isso seria

Lambda tem limitação no tamanho do que você pode passar para ele (o que poderia ser feito para funcionar, mas pode ser mais difícil e menos versátil)

Não tenho certeza se atingiríamos essa limitação. Prefiro não incluir nenhum driver de navegador, pois aumenta a complexidade. Eu pensei que esta opção só seria usada combinada com uma grade externa (por exemplo, Sauce Labs ou grade caseira).

O caso de uso de executar todo o teste, incluindo o driver do navegador em um contêiner, deve ser exportado para um serviço que exija uma configuração mais complexa.

Outro problema é que o Lambda tem um limite de 5 minutos, nossa equipe também estava pensando que o Fargate seria uma solução melhor até que a AWS aumentasse o tempo de execução do Lambda.

Lambda tem um limite de 5 minutos

Ah certo, bem, isso praticamente rejeita o Lambda como uma opção para executar testes e2e

Eu gostaria de ver https://github.com/webdriverio/webdriverio/issues/2406 na v5.

Acho que seria ótimo adicionar uma lista de requisitos necessários para poder executar todos os testes de unidade.
Por exemplo, atualmente estou faltando informações sobre você precisar instalar globalmente o bower, você também não pode executar os testes móveis fora da caixa.

Também seria bom se uma instalação simples do npm instalasse todos os requisitos para executar os testes, se possível.

@erwinheitzman , como você deve ter visto, reconstruímos a infraestrutura completa do projeto , o que facilitará as coisas

Eu tenho uma ideia de solicitação de recurso. Execute a injeção de script por meio do babel correspondendo ao env no qual o script será injetado. Isso me permitirá fazer isso com um exemplo hipotético:

 var result = browser.execute((...numbers) =>  {
   const result = numbers.reduce((total, value) => total + value);
   return result;
 }, 1, 2, 3, 4);

em vez de

var result = browser.execute(function(a,b,c,d) {
  var result =  a + b + c + d;
  return result;
}, 1, 2, 3, 4);

Atualmente, testamos versões mais antigas do IE e usamos a sintaxe antiga do ES apenas porque é mais previsível que funcione.

@mhemesath parece uma boa ideia .. em geral, devemos compilar automaticamente arquivos de teste e script injetado com babel se estiver configurado .. semelhante ao que Jest está fazendo

Ideia: lançar um aviso se o webdriver.io estiver configurado com um maxInstances maior que os hubs maxSession ou slotCounts.total . Parece que exceder qualquer um desses pode levar a erros ou tempos limite.

Esta informação deve ser possível obter através da API do hub:

curl http://localhost:4444/grid/api/hub
{  
   "success":true,
   "capabilityMatcher":"org.openqa.grid.internal.utils.DefaultCapabilityMatcher",
   "newSessionWaitTimeout":300000,
   "throwOnCapabilityNotPresent":false,
   "registry":"org.openqa.grid.internal.DefaultGridRegistry",
   "cleanUpCycle":5000,
   "custom":{  

   },
   "host":"10.0.0.3",
   "maxSession":10,
   "servlets":[  

   ],
   "withoutServlets":[  

   ],
   "browserTimeout":100000,
   "debug":false,
   "jettyMaxThreads":-1,
   "port":4444,
   "role":"hub",
   "timeout":90000,
   "enablePassThrough":true,
   "newSessionRequestCount":0,
   "slotCounts":{  
      "free":0,
      "total":5
   }
}

Ser serviços parece ser a forma padrão de integrar uma configuração de hub ao wdio; parte de mim acha que a configuração maxInstances deve vir do serviço que fornece a integração selênio/navegador. O Selenium autônomo provavelmente faria apenas 1-5 sessões, enquanto um serviço de Hub executaria a API acima para configurar isso dinamicamente. Também tenho certeza de que o saucelabs tem uma maneira de devolver o número de sessões que podem ser executadas.

Eu amaria ter

2208

@tavares111 por favor, sem bugs, apenas recursos que ainda não existem

@dguzmanSM @kevinmcdonnell voltando à ideia Lambda vs Fargate. Eu acho que um limite de 5 minutos é bom. Ao executar mais coisas em paralelo, o tempo de execução do arquivo de especificação real diminui e não deve exceder 5 minutos.
O fato de ser necessário construir um contêiner para Fargate é problemático. Deve ser o mais fácil possível executar algo em uma máquina remota. Ter o Docker como dependências não é realmente "fácil".

@christian-bromann @kevinmcdonnell já que parece que estamos seguindo a rota da função lambda, achei que seria bom ressaltar que o Google tem um produto semelhante (leia: _competindo_) ao Lambda chamado Google Cloud Functions .

Seria ótimo se pudéssemos ter plugins de serviço para suportar ambos. Talvez algo para investigar após a conclusão do serviço lambda inicial.

@patthiel sim, vai! Vou criá-lo em cima do serverless , que oferecerá suporte a vários provedores de nuvem, incluindo o Google Cloud Functions

pessoal, que tal fazer scroll() retornando o elemento web?
será útil em "pipelines" como este

$('div.some.classes').scroll().click();

Apenas para informação: Acabei de implementar isso e, como já vi muitas pessoas fazendo isso, pensei em incorporá-lo nativamente. Então, em muitos casos, você tem esse comportamento:

const elem = $("selector")
elem.waitForVisible()
elem.click()

Na v5 faremos a espera por você. Verifica se a consulta inicial encontrou um elemento e, caso contrário, aguardaria um tempo específico (configurável nas opções). Então tudo que você precisa fazer é:

const elem = $("selector")
elem.click()

No entanto, caso o elemento não possa ser encontrado mesmo depois de esperar por ele, falharemos no comando onde você queria usá-lo (por exemplo, aqui quando você chama click).

@christian-bromann é uma ótima ideia, pois vejo esse padrão em todo lugar. 👍

O Capybara faz algo assim com o método find, ele aguarda um período de tempo configurável para que um elemento apareça e, caso não seja encontrado, lança uma exceção. Ele também falha se encontrar mais de um elemento que corresponda ao seletor, aqui está o documento

Eu acho que seria bom ter um pouco mais de log por padrão. Estou pensando em cada corrida incluir:

navegador e versão (acabei de perder algum tempo com isso, pois meu ci env estava executando uma versão diferente do meu dev env local)
caminho para logs (selenium/chromedriver etc) pode ajudar na descoberta desses logs para recém-chegados

provavelmente há mais que são suficientemente sucintos para que possam ser exibidos para economizar tempo em vez de ter que reexecutar testes com verbose

Eu adoraria ver o suporte para Jest como um executor de testes fora da caixa. Se isso suportar a separação para testes de unidade/webdriver, seria incrível.

Além disso, um melhor suporte para docker/docker-compose com grade de selênio seria bom, pois parece que mais e mais projetos estão sendo conteinerizados.

@aamorozov o que o jest runner fornece para o teste e2e? É um excelente runner para testes unitários, mas não é muito útil para testes e2e. Onde você define os recursos e outras opções? Eu recomendo usar wdio com jasmine que lhe dá quase as mesmas afirmações que com jest.

@christian-bromann
A única razão que tenho em mente para isso é que nossa equipe de desenvolvimento está usando jest para testes de unidade, e seria muito conveniente encontrar uma maneira (se puder ser implementada) de usar jest para testes e2e também. Eu concordo que existem certas complicações, mas eu vi que você já fez algum trabalho aqui https://github.com/christian-bromann/jest-environment-wdio , e eu me pergunto se é algo que você gostaria de incluir para v5 .

@aamorozov Eu estava apenas investigando como uma integração poderia se parecer, mas como mencionei acima, não há valor em adicionar jest como executor de testes para executar o teste e2e. Será mais provável que eu implemente um ambiente jest para executar testes jest no navegador como o karma faz. Se você quiser ter asserções do tipo jest, use o wdio com o adaptador de estrutura jasmine.

Fechando isso. Muito obrigado a todos por seus comentários e contribuições. Se você tiver qualquer outra solicitação de recurso, basta criar um problema normal no GitHub. Obrigada!

Como abrir multiremote com vários URLs.