Cross testing com Ruby, Cucumber e Appium

Tudo começou quando pegamos um projeto novo aqui na empresa. No projeto estamos atendendo somente os aplicativos de Android e IOS, ambos nativos. Com isso, surgiu a possibilidade de criarmos algo novo, que contemplasse com facilidade e agilidade a criação e execução dos testes para as duas plataformas pretendidas.

Ideia principal

O primeiro passo que precisávamos desenvolver era o mapeamento de tela, que é um ponto de grande dificuldade, porque, como mostrado na imagem, são steps distintos, que precisam ser implementados separadamente. Já a base do teste, métodos auxiliares e os cenários de execução, é somente uma para as duas plataformas e a execução também é distinta.

Por que utilizar Ruby, Cucumber e Appium?

* Como superar as dificuldades ao criar testes automatizados mobile em múltiplas plataformas (Android e iOS)? A criação de testes para dispositivos móveis é mais complicada, devido às características específicas de cada device. Solucionamos isso com o Appium (appium_lib), que possui uma pequena abstração utilizada por ambas as plataformas (Android e iOS)

* É possível escrever um único teste para ambos? Sim, é possível. Utilizamos o rake para fazer a seleção das configurações e a busca dos elementos da tela. Após isso, o pageObjects se encarrega de fazer os métodos da tela.

* Qual linguagem utilizar? E a curva de aprendizagem? As principais propostas eram Java e Ruby. O Java teria muitas dependências, como ter um curva de aprendizado maior e depender sempre de uma IDE. Já o Ruby, se demonstrou muito mais prático na aprendizagem, tem fácil leitura de códigos e fácil execução, não dependendo de uma IDE.

Então, nossa solução já estava quase pronta, só precisávamos modelar com a linguagem escolhida.

Estrutura de pastas

• app: Onde colocamos os aplicativos Android e IOS dentro das suas respectivas pastas, ficando app/android/app.apk e app/ios/app.ipa
• config: Onde colocamos as configurações passadas para o appium_lib, também em suas respectivas pastas config/android/appium.txt e config/ios/appium.txt
• features: Dentro da pasta encontramos o core da aplicação, que contém os elementos das views, os cenários de testes, os objetos de página e steps dos testes. Dentro também tem a pasta chamada support aonde temos algumas classes auxiliares para utilização.
• rake_tasks: aqui é onde boa parte da mágica acontece, onde é possível rodar um teste para uma determinada plataforma com um simples comando.

Config

A configuração é uma parte bem simples e possivelmente já familiar a todos. Aunica coisa que foi modificada foi a utilização de um arquivos txt para o armazenamento destas configurações.

Dentro da pasta config/android ficou o arquivo appium.txt:

Dentro da pasta config/ios ficou o arquivo também com o nome appium.txt:

Features

Dentro da pasta features encontramos uma estrutura de pastas e também os cenários de testes, vou começar falando sobre a pasta elements.

Elements

Dentro da pasta elements encontramos vários arquivos .yaml, YAML é um formato de serialização de dados legíveis por humanos inspirado em linguagens como XML, tem a seguinte estrutura.

Esses arquivos yaml são dividos por telas do app, assim facilitando a busca dos elementos e podendo implementar a lógica do teste, antes da tela ficar pronta.

Page Objects

Pages é basicamente uma abstração para a criação dos objetos de página, onde ocorre a paralelização dos métodos do Appium com os elementos capturados por nós.

Step definitions

Esta já é uma estrutura comum quando trabalhamos com o Cucumber e Ruby, onde implementamos a lógica dos cenários de testes para a execução.

Support

Dentro da pasta support implementamos todos os arquivos auxiliares, seja para a definição do ambiente, para abstração de algumas funções do Appium, as funções que mapeiam a tela e também alguns hooks.

Screen mappings implements

Dentro da pasta support colocamos um arquivo com o nome de "screen_mappings_implements.rb" com somente uma função dentro dele, mapear as elementos por plataforma recebida nesta função. Essa função recebe uma tela e um pacote para poder ter diferenciação entre telas e times dentro de uma mesma automação.

Env

O arquivo "env.rb" é onde fizemos toda a lógica dos ambientes para assim buscar as configurações de cada plataforma e também fazer o load no Appium para determinada plataforma.

A única função existente no arquivo é "load_appium_configuration" que recebe a plataforma. Essa função é responsável por fazer o carregamento do arquivo com as configurações do Appium para cada plataforma.

Abaixo temos algumas verificações de segurança e um case para verificar se é android ou ios. Armazenamos esta info em uma variável com nome de caps (capabilities).

Por fim, fizemos o Driver.new do Appium para as configurações saírem funcionando, tanto para iOS quanto para Android.

Hooks

Temos um arquivo com o nome de hooks.rb. Este arquivo é responsável por conter o Before e o After, para dar o start e o quit no início e final de cada teste.

Appium custom

E por último, temos o "appium_custom.rb" que é a customização de alguns métodos do "appium_lib", simplesmente abstraindo eles para que eu use somente um método independe da plataforma ou localização.

Rake

E para finalizar com a execução independente de cada teste, criamos um arquivo ".rake" para fazer os reports dos testes chamar o cucumber, utilizar as tags que o cucumber disponibiliza.

Então, chegamos ao ponto em que utilizando apenas o comando "rake run_acceptance[android,@suatag]" ou "rake run_acceptance[ios,@suatag]", podemos rodar um teste para cada plataforma com menos reescrita de código, não realizando a duplicação de cenários e podendo ser mais ágil na composição dos testes.