Detalhes do Grupo Particular

Global Moderators

Forum wide moderators

  • A documentação dele é bem interessante, e se for ver anda sendo bem escrita. Ainda não existe muito material por que a comunidade está “virando” para usar…Existem migrações e novos projetos sendo feito…Teoricamente precisa de mais um tempo para estabilizar.
    Link dos docs: https://flutter.dev/docs/codelabs

    Ps: até que essa classe tem algumas coisas interessantes…Mas talvez precise amadurecer um pouco mais… https://api.flutter.dev/flutter/flutter_driver/FlutterDriver-class.html

    postado em Geral
  • Assim, eu realmente não conheço muito sobre a ferramenta que estão usando, mas o link que passei era para usar webdriver “puro” …e um dos links que passaram fala abertamente que o touch_actions implementado por eles é para mobile…então não sei se é hora de avaliar os prós e contras do que estão usando ou tentar um bind direto com o webdriver pelo framework que escolheram… (dai não é algo simples, precisa saber como o webdriverIO funciona para “tapear” ele…vai dar trabalho e não deve ter nada pronto…)
    Como foi dito (e mandado link) O webdriver fornece como trabalhar isso com o touch_actions
    E se forem ver nas issues do projeto, tem uma aberta para implementar isso (devido a problemas com puppeter)… https://github.com/webdriverio/webdriverio/issues/4457
    Infelizmente não tenho como ajudar com esse framework… Mas vale a dica, tentar algo diretamente com o webdriver e ver se funciona. Pois notei que o problema nem é com o hammer.js, mas com o framework que escolheram para a automação (a não ser que tenha perdido algo nessa conversa…o que pode ter acontecido…Dado que não mexo com esse framework…ehhehehe)
    Ps: não chegaram a procurar nada no npm ? normalmente tem trocentas libs que ajudam para coisas simples…

    postado em Geral
  • Me tira uma duvida boba, estão tentando fazer isso em um device tipo android ou iOS ou estão tentando em um navegador comum mesmo? Pelo projeto de exemplo eu não vi nada relacionado a mobile…E esse touch_actions espera tu passar um driver de android ou iOS para poder mandar o comando nativamente…E ao ver esse erro de bind ele deve estar esperando esse contexto, e au não achar retorna que foi undefined
    E cada vez passando doc do appium me deixou curioso…

    postado em Geral
  • Se está inserindo no mesmo campo, é capaz de rolar esse problema com o set …Senão é necessário limpar o campo, pode ser como falaram, usa o send_keys …Ou se é campos diferentes, pode clicar nele antes de passar um set …Mas dai já bem workaround…ehhehehe

    postado em Geral
  • Se ajudar, tem documentação sobre touch_actions para javascript (pelo webdriver): https://seleniumhq.github.io/selenium/docs/api/javascript/module/selenium-webdriver/lib/input_exports_Actions.html
    Talvez possa ajudar com a lib que estão usando…

    postado em Geral
  • A documentação fala sobre ser apenas para app nativos e webapps…Nesse exemplo não vi configuração comentando sobre mobile…E já chegou a testar sobre tap com tempo de espera para release tambem?
    (chegou a ver a documentação do webdriver? se essa lib usa webdriver e appium por baixo, talvez possa invocar diretamente o que precisa da lib e abstrair algo na unha).

    postado em Geral
  • Senão me engano o sonar tem uma API onde se pode captar essa metricas…talvez possa usar para gerar um json e consumir em algum relatório.

    postado em Geral
  • Na verdade existe a Touch_actions, nela tu poderia efetuar um long_press. Dá uma olhada na documentação…O que me recorda, no webdriver, era usar isso para manter pressionado algo por alguns segundos e depois soltar…

    postado em Geral
  • Ok, vamos desmebrar um pouco esse “samba”…

    1. emular o ambiente aonde eu consiga inserir o mesmo registro sempre sem precisar mudar minhas features
      Mas tu precisa fazer uma operação antes no banco de dados para depois consumir no front, ou todas as ações acontecem no front? O problema é fazer isso no front ou ter que preparar antes para consumir?
    2. questão de não usarem data_test_id nos campos e o campos sempre ficam com ids dinâmicos
      Dependendo da tecnologia o retorno pode ser dinamico…Eu recomendo tentar ser mais “incisivo” na parte de ter test_id ou se for caso perdido, tentar manejar por CSS ou outros pontos menos volateis…onde os testes falham…

    Como parece que sabe os fluxos e as tecnologias usadas, vale pensar e analisar se os testes precisam ser feitos todos no front…Talvez alguns possam ser responsabilidade só do banco de dados e o front apenas “passa” sem ter nenhuma responsabilidade em cima disso…
    ps: Se não usar BDD, pode resolver muitos problemas tambem…pense nisso…ehehheheheh

    postado em Geral
  • Eu gosto de entender o motivo das perguntas, quanto a duvida no geral…

    No caso os dois exemplos que passou, um é um framework (selenium based) para fazer automação. O outro é um local para executar os testes nativos feitos para android e iOS (pelo que me recode iOS ainda estava beta)
    A abordagem ai é que se separa. Se for escolher o local para executar, os testes vão ser nativos. Ou seja, junto ao código.
    Se for escolher appium, tem uma margem de outros locais para rodar, mas não diretamente no firebase…

    Por isso, se souber explicar mais no que está pensando em citar esses dois exemplo, talvez ajude a comunidade responder de um modo melhor…

    postado em Geral