Group Details

MVP

Destaques da Comunidade

 
  • RE: Problemas com o protractor-retry

    Nunca ouvi falar…Ohhh @Walmyr … Já chegou a usar isso?

    posted in Geral
  • RE: Dúvida sobre Pós-Graduação

    @paulo-gonçalves É que em alguns casos, page objects pode não ser a solução. Por isso comentei em estudar design patterns…

    posted in Geral
  • RE: Dúvida sobre Pós-Graduação

    Não quero desmerecer, mas se gostaria de trabalhar mais com automação de testes, deveria escolher alguma linguagem e , ao menos, criar uma aplicação. Os materiais passados acima são uma ótima referencia.
    Se escolher alguma linguagem de programação, coloque na lista sobre design patterns. Vejo uma galera aprendendo a programar, fazendo algumas coisas e é um spaguetti code doentio…
    Fora que aprendendo a programar, tu começa a visualizar um pouco como testar o que está criando. E isso depois para o profissional é muito bom.
    Ah, e os frameworks estão ai, mas aprenda primeiro um pouco da linguagem. Pessoal atropela framework sob linguagem…

    posted in Geral
  • RE: Material para iniciar com testes mobile

    Tem esse blog que acho muito bacana:
    http://adventuresinqa.com/
    e o cara tem um livro que também é interessante (é meio confuso, ele dá umas misturadas legais no explicar, mas é bom)
    https://www.amazon.com.br/Hands-Mobile-App-Testing-Involved/dp/0134191714

    E mais esse blog que também achei legal:
    http://continuoustesting.blog/

    posted in Geral
  • RE: Como manipular notificações nativas Android e iOS?

    Sim, só ao rodar iOS não passa ela. Eu acho que não quebra nada, mas né…nunca usei com ruby e não sei o que pode acontecer…No demais, o que rolar de dúvidas, só avisar…

    posted in Geral
  • RE: Como estruturar testes automatizados?

    E não querendo ser chato, se está usando pageFactory, e caso não viu FluentWait, por favor: Veja!..o pooling ajuda pra caramba com problemas de elementos não encontrados e exceções que ocorrem…

    posted in Geral
  • RE: Como estruturar testes automatizados?

    Well, vamos por parte:
    Eu entendi a questão das dependencias. O problema me parece é que tu está utilizando dados os quais podem ter o que tu precisa ou não. E tu está tentando confirmar isso a nível de interface. E para isso não existe mágica. Tu vai ter que criar alguns “try/catch” em certos pontos do teste. O que tu pode deixar no base, é algo relacionado ao que precisa para testar.
    Se é público ou privado, isso não é a importante, na minha visão, nesse momento.
    O teu problema é “mais acima”.
    Se tu não pode manipular os dados “on the fly”, a escolha menos ruim (veja bem, nesse ponto não existem soluções boas…só "workarounds menos dolorosos) seria tu ter uma suite só para gerar os usuários com o que tu precisa e na hora de rodar tu usar isso.
    Pode resolver? Talvez sim…Talvez não…Mas pode te isentar de ficar cobrindo teu teste de try/catch.
    Se nem isso resolve. O que posso dizer é, cria no teste os métodos para tais modificações para não ter conflito com outros testes. E se quiser reaproveitar, cria nas classes de ações dentro do pagefactory e utiliza inicializa elas dentro dos testes e usa.
    Mas como falei, para esse tipo de problema, via app não existe solução boa…só “cover your ass points”…

    posted in Geral
  • RE: Como manipular notificações nativas Android e iOS?

    Olá, com appium tu tem uma capabilities que , para android somente, tem a opção

    AndroidMobileCapabilityType.AUTO_GRANT_PERMISSIONS
    

    Com ela tu resolve isso pois ela dá permissão para tudo que o app precisa antes de iniciar os testes.
    Para iOS ferrou. Isso é um problema sem solução, pois a ferramenta nativa (XCTest) também não suporta.
    Para iOS tem que pedir para colocarem as permissões no inicio do app, para tu aceitar todas, ou ficar cuidando alerta e dar um accept.
    não sei com ruby, mas em java tem

    driver.switchTo().alert().accept();
    

    E esse carinha aceita isso.
    Ou se quiser ficar cuidando se o alerta aparece, também pode. Mas vai ser uma porcaria dar manutenção a isso e teu teste vai ficar instável (aka flaky).

    posted in Geral
  • RE: Como estruturar testes automatizados?

    Dependendo do que se usa, tu pode colocar uma prioridade, ou executar tal teste e depois. Eu sempre deixo os meus testes independentes para conseguir uma certa elasticidade quando quero executar.

    Sobre o método eu falei mais no fim. Mas acho que não resolve o seu caso. Tu poderia criar um método publico para tal situação em uma outra classe para utilizar dentro de um after ou before test se precisar.
    Ou até uma interface se quiser deixar bem estranho.hehehe. O ponto, pra mim é: Tu precisa definir onde quer colocar o que vai usar para entender como elaborar o uso.
    Ex: Se tu tem uma classe de Setup, e tu extende ela para as classes de teste, poderia ver em deixar na de setup o que quer usar e não precisaria implementar na de testes.
    Talvez se expor um pouco da arquitetura que utiliza, podemos entender melhor o problema.
    Testes que envolvem CRUD (create, read, update and Delete) eu sempre tento fazer os dados que vou utilizar antes (e no fim deleto se posso). Quando estou em ambientes que não tenho muito acesso, eu normalmente crio um serviço para fazer isso. Ou um sql script. O que quero deixar dito é: eu não deixo a responsabilidade de deletar/criar o que uso dentro do app que estou usando. (Salvo casos que o app seja nativo e não comunica externamente com nada, fica tudo salvo no app).
    Nesses casos, ainda tem como resetar o app (se resolver deletar tudo) ou procurar meios de deletar via linha de comnado.
    Não sei se consegui ser “entendível”…hehehe

    posted in Geral
  • RE: Como estruturar testes automatizados?

    A minha opinião é: tente fazer os seus testes o mais independentes possíveis.
    Criar muitas dependencias (de massa de dados, ou ações para poder prosseguir, etc…etc…) podem deixar os testes instáveis (ou flaky’s no jargão popular) e a manutenção ou execução podem ser dolorosos. O que aconselho é ter um pré-step onde tu pode validar a massa de dados que vai utilizar. Se puder criar melhor.
    Caso seja como grande maioria, sem poder de elaboração da massa de dados, pode se tentar reduzir o flakiness em uma condição antes do teste para limpar os dados, ou pelo menos analisar ela antes de usar. Assim tu consegue antes de iniciar tu já pode ter a informação que precisa antes de sair executando e ter um problema lá na frente.

    Sobre métodos privados ou públicos. Dependendo da estrutura, pode ser um método publico dentro da ações da tela que está, o qual tu pode chamar no teu teste e executar o que precisa. Se deixar ele privado na classe de teste não é algo que gosto não…Mas é um pensamento meu…

    posted in Geral