A todo momento são desenvolvidas novas funcionalidades para os aplicativos que, sem dúvidas, devem ter o pleno funcionamento garantido como o esperado. Para isso, deve-se testar o app toda vez que é realizada alguma alteração em seu código. Muitas vezes, o teste é realizado manualmente. No entanto, essa forma pode não ser eficiente e não cobrir todos os aspectos do software.
Como não queremos que bugs prejudiquem a experiência do usuário, surgiu a necessidade de implementar outras formas de testes, os automatizados. Isto é, aqueles que são executados automaticamente pela máquina utilizando um emulador Android ou um dispositivo físico.
Este artigo irá abordar os testes BDD (Behavior Driven Development) para escrever testes de aceitação, com o propósito de reproduzir o comportamento de um usuário executando tarefas dentro do app.
Com os testes em mãos é possível desenvolver com mais tranquilidade, evitar bugs e subir uma nova versão sem o frio na barriga por não saber se o app está estável. A longo prazo, os testes garantem mais tempo de desenvolvimento e menos tempo de correções. Para implementação pode-se utilizar as ferramentas Espresso e Cucumber. Se você nunca ouviu falar em nenhum desses nomes, este artigo é para você!
O que é o Espresso?
O Espresso é um framework feito especialmente para a implementação de testes de interface em apps nativos na plataforma android. Ou seja, com ele podemos simular a interação do usuário em comandos como clicar, digitar, verificar elementos de layout, verificar se o texto está correto, entre outros. Como dito anteriormente, essa simulação se faz de maneira automática em um dispositivo físico ou em um emulador android.
O Espresso é usado para testes caixa preta, ou seja, testes que não interagem com o código fonte do app. Sendo assim, não é necessário conhecer o código para implementar o teste, somente interagir com os elementos em tela.
Para auxiliar a implementação dos testes, pode-se utilizar a ferramenta Record Espresso Test. Esta ferramenta irá gravar toda interação feita pelo desenvolvedor no emulador ou dispositivo, gerando uma classe com todas as interações feitas e os identificadores referentes a cada objeto, mostrando o poder do Espresso em relação ao teste caixa preta.
Um dos comandos básicos do Espresso é chamado onView(), o qual, a partir dele, pode-se referenciar um elemento na tela que, por sua vez, é buscado através da hierarquia do layout na tela em que o usuário se encontra. Para utilizar este método é necessário atribuir como parâmetro alguma característica do elemento que se busca, seja ela um identificador como R.id, texto ou hint. Assim, podemos fazer operações com o elemento.
As operações principais são o perform e o check, o qual o primeiro permite que o desenvolvedor realize um click na tela, digite um texto, role a tela até o elemento ou feche o teclado do aparelho. Enquanto isso, o operador check permite que seja feito uma verificação, ou seja, conferir se um elemento está ou não visível na tela, se um texto está escrito como esperado, se existe uma imagem, se é mostrado alguma notificação ao usuário, entre outros.
Um exemplo de uso de todos os recursos que foram abordados seria:
Observe que, após o comando do Espresso, foi adicionada uma linha de código. Esta diz para o sistema aguardar 3 segundos. Esse período é necessário, pois, após alguma ação como click, o tempo de resposta do servidor pode ser mais lento que o tempo do Espresso executar outra ação, fazendo com que o teste falhe. Porém, embora este seja o método que utilizo, ele não é o melhor para colocar a Thread em pausa, o ideal seria implementar o IdlingResource.
Em suma, o processo de ações no Espresso se dá em achar um elemento, realizar alguma ação e verificar alguma condição (pode-se também somente achar o elemento e verificar a condição).
Se você quiser saber mais sobre os comandos básicos do Espresso basta acessar a documentação oficial.
O que é Cucumber?
É certo que, se os fluxos dos aplicativos estiverem documentados, toda equipe é capaz de entender como o software funciona. A documentação é importante para quem já conhece o app e para quem começou a desenvolvê-lo agora.
O Cucumber ajuda a desenvolver esta documentação dentro do projeto, utilizando o plugin Gherkin que é capaz de reconhecer textos escritos em linguagem natural e interagir com classes específicas dentro do projeto.
Sendo assim, o processo para a interação entre o texto e o projeto se dá em escrever um arquivo chamado feature, o qual é descrito os cenários de teste e dentro de cada cenário temos o fluxo correspondente ao que se deseja testar. Dessa forma, pode-se ter um cenário de sucesso para o fluxo e vários outros cenários em que o fluxo falha em concluir.
É importante desenvolver tais cenários, pois queremos saber se um texto digitado incorretamente irá continuar com o fluxo, se um documento foi inserido pelo usuário de forma incorreta e uma mensagem de erro foi exibida, entre outros cenários que podem ser testados.
Com o arquivo feature em mãos, deve-se escrever o arquivo steps — uma classe usada para implementar o Espresso para os cenários. Portanto, cada linha escrita em linguagem natural será implementada através de uma função no arquivo steps e dentro de cada função deve-se colocar os comandos Espresso. Assim temos a descrição do que cada passo faz e logo abaixo a sua implementação em Espresso.
A estrutura do arquivo feature se dá em uma declaração com o nome da feature, e os cenários que são definidos por uma tag que serão lidos e reconhecidos pelo arquivo steps. Após declarar a tag, deve-se declarar qual o tipo de cenário. O tipo mais utilizado é o Scenario Outline, sendo possível criar tabelas de exemplos que dirão o que vai ser dado de entrada em determinado momento entre os passos do fluxo.
Logo após a declaração do tipo de cenário, podemos começar a escrever nosso fluxo que, por sua vez, é escrito com palavras chaves e texto. As palavras chaves mais frequentes são Given (pré condição), When, And e Then (as palavras chaves podem ser configuradas para serem escritas em português).
Para finalizar o Scenario Outline, deve-se criar a tabela de exemplos a qual, quando o teste for executado, o cucumber irá usar seus dados para criar um teste individual para dados de entrada diferentes para cada linha da tabela. Um exemplo de cenário da feature seria:
A estrutura do arquivo steps se dá em declarar as tags @Rules para abrir a activity desejada, garantir permissões, além de outros usos. Após as Rules, deve-se declarar as tags @Before e @After, que são executadas antes e depois de cada cenário de teste respectivamente e ditam configurações desejadas.
Após as declarações iniciais podem ser implementados os steps propriamente ditos, sendo necessário declarar um @ seguido da palavra chave; entre parênteses e aspas deve conter o texto referente ao step desejado e logo abaixo ter constado a declaração da função com os comandos Espresso.
Um exemplo para a declaração do steps e integração com o Espresso seria:
Note que o texto está entre ^ e $. Esses elementos são necessários para o reconhecimento do texto. Note também que no lugar de <email> foi passado o elemento (.*?),substituição fundamental para que o Cucumber entenda que ali existe uma variável para buscar na tabela anteriormente criada no arquivo features.
Configurações
Para utilizar o Espresso junto com o Cucumber deve ser feita algumas configurações, iniciando pelos plugins: instalar os plugins “Cucumber for Java” e o “Gherkin”.
Para o Gradle deve ser adicionado o seguinte código:
Deve-se também adicionar as seguintes dependências:
Para o cucumber funcionar, foi criada uma classe chamada de Instrumentation, a qual é feita as configurações de tags, caminhos para as features e para os steps. Essa classe é o que vai ditar nossos testes e é essencial para o projeto. Não se preocupe em configurá-la, pois ela é padrão para qualquer projeto, bastando somente colocar o caminho para os testes. A classe é descrita abaixo:
Note que em @CucumberOptions temos os caminhos para se encontrar os arquivos de features e steps, as features ficam dentro de uma pasta de mesmo nome dentro de uma outra chamada “assets” na variante androidTest (fora da pasta main, app/src/androidTest); já os steps ficam dentro da pasta PACKAGE_NAME.test, também na variante androidTest. Com isso temos nosso projeto configurado e pronto para rodar testes!
Continuous Integration e Continuous Delivery (CICD)
Como estamos desenvolvendo testes automatizados, nada melhor que automatizar a execução deles. Para isso temos o CI/CD, em que toda vez que fizermos um push em uma branch do git, os testes serão executados em nuvem e publicados na loja automaticamente.
Existem várias plataformas para publicação, sendo as mais conhecidas: Jenkins, CircleCi, Bitrise.io, GitLab, entre outras. Basta você escolher a que mais te adequa. É extremamente recomendado implementar o CI/CD para que ele possa ser testado automaticamente toda vez que ocorrer alguma modificação no app.
Conclusão
Inquestionavelmente, os testes garantem muito conforto ao implementar novas funcionalidades. Os testes BDD, que simulam a interação com um usuário, são ótimos, pois vemos o comportamento do sistema com um usuário real.
O Espresso e cucumber são ótimas ferramentas para o teste caixa preta e conversam muito bem entre si, além de fazer toda a documentação de fluxo do app. Ambas as ferramentas são recomendadas para trabalhar com CI/CD, visto que otimizam o tempo para que os testes não tenham delay e possa tudo ocorrer de forma rápida. Atualmente eu não consigo ver um app sendo desenvolvido sem a fase de teste.
Espero que este artigo tenha despertado seu interesse e tenha ajudado no pontapé inicial. Happy Testing!
