Alternativas ao Thread.sleep()

Topic created · 9 Posts · 125 Visualizações
  • Olá galera, tudo tranquilo?

    Uma coisa que me mata aos poucos é encontrar um Thread.sleep(30000) em um teste, mas muitas vezes não tem o que fazer.

    No casso dessa espera matadora de 30 Fuc**** seconds o teste tem que aguardar a execução de uma rotina, que dependendo do momento de execução precisa mesmo desse tempo todo.
    O problema é que as vezes a rotina é executada em 5s e ai lá se vão 25s a toa.
    E é chato tbm ver o Sonar acusando code smell.

    Bom, não estou me referindo ao caso que citei, gostaria apenas de saber algumas coisas.

    Vocês usam alguma forma alternativa para essas esperas? (API, Bibiloteca, classe marota desenvolvida por um gênio da computação que passou pelo cod que vc trabalha)

    No meu caso uso Java, essa dor se aplica a sua linguagem de trabalho tbm?

    Conta ai péssimas praticas que vocês já viram em códigos que usavam o Thread.sleep()

    Vlw!

  • Opa @lmart, beleza?

    Já tentou usar o FluentWait?

    https://blog.testproject.io/2019/12/10/smart-selenium-waits-fluent-wait-avoid-flakiness/

    No meu projeto de automação aqui retirei todos os Thread.sleep e analisei caso a caso. Alguns foram resolvidos com essa alternativa.

  • Poxa @ronunes legal o FluentWait vou testar nas automações que usam o selenium.

    Legal que da pra impor uma lista de execeptions que quero ignorar enquanto ele aguarda o elemento e tbm que ele já está no pacote do selenium, nem precisa importar nada. Pena que precisa do driver pra usar.

  • o que é essa rotina? vc consegue fazer polling dela?

  • Mas está usando o que de framework para testar?

  • @Leonardo-Galani é uma rotina automatica para etls executada por uma aplicação externa, fora do domínio de teste, mas minha pergunta não tem relação com ela, foi apenas para exemplificar a dor de ver um Thread.sleep() de 30s

  • @Ramses-Saccol-de-Almeida a grande maioria e escrito em Java com Spring Boot e cucumber, e alguns usam Selenium. Gosto de usar tbm o lombok e Testng mas alguns ainda usam jUnit e são feitos “na tora” sem muita ajuda do Spring e lombok. Tem tbm os mobile com appium… Mas uma coisa todos tem em comum, um Thread.sleep() perdido 😅

  • Eu to perguntando pq vc não precisa colocar um wait grande se vc pode fazer polling de resultado de execução.
    Se é um processo… e parece que vc usa java… da pra fazer uma thread especifica para esse seu processo… e a thread termina quando ele acaba… vc so precisa checar se a thread acabou (denovo… polling) para seguir com seu teste.

  • @lmart Então, se tem um sleep perdido, já sabemos que code review tá passando longe do projeto.
    Mas independente disso, é preciso entender com o que se está mexendo para saber o que utilizar. Os exemplos mencionados normalmente utilizam algum tipo de pooling, retry ou similar para não ficar a cargo de esperar algo…
    A linha de pensamento deve serguir nessa linha, uma execução automatizada não deveria esperar para fazer algo, mas deveria efetuar tentativas de validar a condição do que precisa para seguir adiante.
    Claro, deixar infinito não é uma boa para processamento, mas com um tempo definido reduz um pouco de deixar uma “thread” parada…