Calabash Android – Criando os primeiros testes

Neste post, criaremos os primeiros cenários de teste utilizando apenas as bibliotecas já implementadas pelo Calabash. Como exemplo para este post, usarei o aplicativo Omni Mensagens desenvolvido na Take.net.

Caso não tenha acompanhado nossos posts, confira a Parte 1 e Parte 2 da instalação. E para aprender a criar um projeto no Calabash, clique aqui.

Inspecionando os elementos do aplicativo

Para criar os testes do Calabash, é preciso inspecionar os elementos do aplicativo, tais como id’s, content description, class e outros elementos necessários para as validações dos cenários de teste. Existem duas maneiras fáceis de encontrá-los.

1. query”*”

O primeiro deles é fazendo uma query na tela. Com o aparelho conectado ao computador, abra o CMD na pasta que contém o arquivo.apk. Execute a linha de comando calabash-android console nomeDoApk.apk. Depois, execute a linha de comando start_test_server_in_background. O aplicativo será inicializado no celular. Navegue (no próprio aparelho) até a tela em que deseja inspecionar os elementos e execute o comando query”*”. Não é uma forma muito intuitiva de encontrar os elementos do aplicativo caso os id’s não tenham nomes indicando a ação, como por exemplo “start_button”.

query"*"

query”*”

 

2. UI Automator Viewer

Outra forma de inspecionar os elementos é utilizando a ferramenta UI Automator Viewer do Android SDK. Essa ferramenta está na pasta tools da pasta Android.

Android SDK tools

Android SDK tools

 

Para inspecionar os elementos do aplicativo, abra a tela em que deseja ver os elementos no celular e clique em Device Screenshot (uiautomator dump) na ferramenta UI Automator Viewer.

Device Screenshot (uiautomator dump)

Device Screenshot (uiautomator dump)

 

Um screenshot da tela aparecerá.  Para ver os detalhes de um elemento específico, basta clicar em cima dele e todas suas propriedades serão listadas.

Elementos da tela

Elementos da tela

 

Criando a primeira feature

Agora que sabemos como encontrar os elementos necessários, vamos começar a escrever nosso cenário de teste.

3. Criando o arquivo .feature

Para criar os primeiros cenários de teste, você pode utilizar um editor de texto como Notepad++ ou outro qualquer de sua preferência.

Salve o arquivo no seu editor de texto com a extensão .feature. Uma dica: salve os seus arquivos no formato 00funcionalidade_testada.feature.  Esse arquivo deve ser salvo dentro da pasta features no projeto criado para os testes.

– 00: ordenação da execução dos testes (00, 01, 02…).

– funcionalidade_testada: descreva de forma breve o que o seu teste faz.

– .feature: extensão do arquivo.

Criando o arquivo .feature

Criando o arquivo .feature

 

4. Criando o primeiro cenário de teste

Começaremos a criar os steps utilizando apenas as bibliotecas nativas do Calabash.

Exemplo de cenário de teste

Exemplo de cenário de teste

 

Observe a figura acima com um exemplo de uma Feature.

Linha 1: é descrita qual funcionalidade do aplicativo está sendo testada.

Linha 3 (Scenario): descreve o que esse cenário faz.

Linha 4: Valida se o aplicativo está na tela de início.

Linha 5: Verifica se contém o texto na tela.

Linha 7: Clica no botão através do id encontrado através da ferramenta UI Automator Viewer.

Linha 9: Espera até que o elemento apareça na tela para executar a próxima ação.

Linha 14: Insere um texto no campo que contém aquele id.

Linha 33: Espera até que a barra de progresso se complete para executar a próxima ação.

Observação: Todo wait tem um timeout implementado. Caso o seu aplicativo demore um pouco mais que o tempo implementado nessas ações, opte por: Then I wait for 80 seconds, por exemplo. No lugar de 80 seconds, pode ser passado qualquer valor.

 

4. Como executar o teste

Criado o primeiro cenário, vamos executá-lo no celular. Para isso, abra o CMD na pasta que contém a apk.

Há três formas de executar os testes:

  • calabash-android run nomeDoApk.apk

Executará todas as features que contém na pasta (na ordem em que aparecem lá, por isso é importante numerá-las, como citado no item 3). Os testes só serão finalizados quando a última feature da pasta for executada.

O aplicativo será desinstalado e instalado a cada feature executada.

  • calabash-android run nomeDoApk.apk ./features/nomeDaFeature.feature

Executará uma feature específica. O teste é finalizado ao final dessa feature específica. As demais não serão executadas.

  • –format pretty –format html -o android_report.html

Ao acrescentar essa linha um report, em formato html, será gerado. Ele contém informações sobre quantos scenarios e steps foram executados. Além disso, ao ocorrer um erro, um screenshot da tela será tirado.

Pasta do projeto - report

Pasta do projeto – report

 

Observação: Em alguns casos, é preciso executar os comandos calabash-android resign nomeDoApk.apk e calabash-android build nomeDoApk.apk.

Para conhecer outros canned steps, acesse esse link.

Em seguida, falaremos sobre a execução dos testes e o report de teste gerado.
Não perca os próximos posts!

Sobre o(a) autor(a)

Letícia Bomfin Ramos
Letícia Bomfin Ramos

Graduanda em Sistemas de Informação pela Pontifícia Universidade Católica de Minas Gerais, iniciando a carreira em 2012 como estagiária da Gerência de Homologação na Prodabel. Hoje, atua como Analista de Qualidade de Software na Take. Apaixonada pela area de qualidade de software, mobile, chatbots e automação de testes. Conquistou o 4º lugar e o prêmio Most Useful Test Report na etapa South America do Software Testing World Cup 2014, ao lado de Samantha (QA), André (QA) e Rhamon (PO).

2 comentários

Comente
  • Bacana, Letícia!

    Gostaria de sugerir uma melhoria no exemplo: não utilizar IDs internos nos steps das features.

    Por exemplo, quando escreveu:

    ‘And I press “startBtn”‘

    Isto amarra o teste a detalhes de implementação (este ID pode eventualmente mudar por conveniencia ou necessidade do desenvolvimento).
    Se escrevesse:

    ‘And I press button “Começar”‘

    Você evita este acoplamento (o layout da tela poderia ser completamente reestruturado que o teste continuaria passando se um botão com texto Começar ainda existisse) e ainda mantém a linguagem próxima do usuário final, que é um dos motivadores de testes de aceitação e BDD.

    O artigo abaixo comenta um pouco mais sobre esta ‘mudança’ de estilo:
    http://www.elabs.se/blog/15-you-re-cuking-it-wrong

    • Bem observado, André Minelli. É muito importante que os testes não sejam amarrados para evitar manutenções no código. E uma vantagem do Calabash é que ele permite utilizar qualquer elemento que ele “enxerga” na tela.
      Obrigada por sua contribuição! 😉

Deixe uma resposta para Letícia Bomfin Ramos Cancelar

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

Você pode usar as seguintes tags e atributos HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

by Take ® 2015 | Todos os direitos reservados.linkedin