Hoje iremos mostrar a estrutura de um projeto de automação com cucumber + ruby + appium.
Se você já veio do nosso último post (algo que recomendo a leitura), onde explicamos o que é, como surgiu, pré-requisitos para a sua utilização e os primeiros passos com o Appium, então não perca este post sobre a estrutura de um projeto de automação mobile.
Caso você ainda não tenha conferido a primeira parte, acesse o link abaixo:
Vamos iniciar de onde?
Presumo que você já tenha todo o ambiente configurado, então vamos colocar a mão na massa. O primeiro passo é saber qual é o app que será testado. Provavelmente você já testa/testou o seu app manualmente e agora está buscando mais uma forma para aumentar a cobertura dos seus testes com a automação. Na verdade a automação irá te ajudar a ter minimamente cenários automatizados para a sua regressão, deixando mais tempo para testar as funcionalidades mais complexas, fluxos alternativos e realizando testes exploratórios. Nesse passo a passo irei utilizar o app da calculadora que já vem no próprio Android Oreo.
“Mas como pego um app que já está instalado no meu smartphone?”
O comando acima mostra todos os pacotes de apps instalados no seu celular.
Copie o package do seu app (depois dos dois pontos):
Digite o comando adb shell pm path e cole o pacote do seu app:
Copie o path do seu app e execute o comando adb pull <diretório copiado> <diretório de destino>.
Para baixar o app no seu diretório atual é necessário dar o espaço e colocar o ponto (no meu caso o app vai para a pasta Desktop).
Criando o projeto
Caso ainda não possua a gem do cucumber, instale com o comando
gem install cucumber
Criando o diretório/pasta do seu projeto:
Agora que você já criou o diretório do seu projeto, acesse ele pelo seu editor de texto favorito (o meu é o VSCode):
Vamos colocar o nosso app dentro da pasta/features/support do nosso projeto:
Agora vamos abrir o arquivo env.rb e iniciar a nossa configuração de ambiente:
Acima carregamos na memória as gems do Appium e do Cucumber, definimos as capabilities do nosso app, iniciamos e finalizamos o driver do Appium a cada execução.
No primeiro post explicamos o que são capabilities, o que significa cada argumento e como conseguir os dados para preenchê-los.
Escrevendo os cenários
Como estamos testando um app de calculadora, nada mais justo do que começar escrevendo o cenário de uma das quatro principais operações de uma calculadora.
Crie o arquivo dentro da pasta features com a extensão .feature e escreva o cenário utilizando o BDD:
Inicie o servidor do Appium clicando em Start Server:
Acesse o seu projeto pelo terminal e execute o comando cucumber:
Nesse momento o Cucumber gera os steps definitions. Mas, como os steps estão indefinidos, o Appium não executará nenhuma ação.
Crie o arquivo multiplicar_steps.rb dentro da pasta step_definitions.
Copie e cole os snippets gerados do seu terminal no arquivo criado.
Na sessão aberta, preencha os campos conforme as capabilities que estão no seu env.rb:
Clique em Start Session e aguarde o Appium subir o app no seu device:
O nosso primeiro step valida se o app foi aberto corretamente. Uma das formas de verificar isso é identificando um elemento do app na tela inicial e validar se ele foi aberto corretamente:
Como nosso app tem um id para identificar a tela principal, podemos utilizá-lo e validar dentro do nosso step:
Agora precisamos multiplicar 3 por 9, de acordo com a nossa especificação do BDD:
Precisamos mapear os elementos da tela que são as teclas 3, 9, operação de multiplicação e o “=”. Faremos isso neste step:
Acima, mudei as variáveis int e int1 para a e b. Em seguida, mapeei os elementos citados.
Dentro dos elementos digit_3 e digit_9, realizei uma interpolação com as variáveis a e b que contêm os valores 3 e 9 que estão nos steps do nosso cenário. Ou seja: quando você mudar os valores do seu BDD, automaticamente esses valores serão passados para as variáveis.
Por fim, faremos o nosso querido assert dentro do Então. Para começar, precisamos pegar o valor do resultado da multiplicação. Como faremos isso?
É só mapear o resultado, verificar se ele possui id (que é o nosso caso) e pegar o texto desse elemento:
O id do elemento é result. Com o método .text pegamos o valor que contém no atributo texto do elemento.
Sabendo disso utilizamos uma condição dentro do nosso teste para caso o valor seja diferente de 27 o nosso Então falhe:
Lendo a nossa condição dá para entender: Falhe “Texto que será apresentado no console” a não ser que o texto do elemento seja igual ao nosso resultado.
Execute o nosso teste pelo terminal com o comando “cucumber” e veja os seguintes resultados:
Outro passo importante é criar o arquivo Gemfile, fora da estrutura da pasta features com as gems que serão utilizadas no nosso projeto:
Essa é a estrutura final do nosso projeto de automação mobile:
Dúvidas que podem surgir ao final do post
Bruno e Thialison, você faz desta forma a automação mobile? Sim e não, esse post mostra uma base de projeto para a sua automação e você pode começar com ele!!!
E o ScreenObjects? Ele fará parte do nosso próximo post, se você faz PageObject no seu projeto Web, já pode tentar neste projeto mobile.
Tentei multiplicar dezenas, quebrou o meu teste e agora? Quanto mais você souber da linguagem que está trabalhando, mais claro ficará para resolver esse problema, a melhor forma seria criando um método que te ajudará a resolver esse inconveniente. Vamos escrever sobre isso nos próximos posts também.
É isso por enquanto pessoal, tentei mostrar de uma forma simples como é a estrutura de um projeto mobile com Appium em poucos passos.
Tem bastante conteúdo sobre isso pela internet, então divirta-se!!!
Bruno Carvalho – Analista de Teste na BRQ
