Os dispositivos iOS ainda reivindicam uma parte significativa do mercado móvel, ocupando até 22% das vendas globais. Como muitos clientes dedicados voltam para novos produtos Apple, há também uma grande demanda por aplicativos iOS. Neste artigo, vamos procurar garantir a qualidade dos aplicativos iOS que se esforçam para o uso das melhores práticas usando as ferramentas Appium, Cucumber e Serenity.

Structure

The Page Object Model é uma das melhores abordagens para testes que os engenheiros de QA podem aplicar a um projeto de automação de testes. É uma forma de estruturar o código em um projeto de automação que melhora a qualidade e legibilidade do código, manutenção de testes e, além disso, é uma ótima maneira de evitar o caos. A idéia básica por trás disso é manter todas as referências a elementos móveis e métodos que realizam operações sobre eles em um arquivo de classe para cada página ou tela da aplicação (ou página web para aplicações web não nativas).

Quais são os benefícios desta abordagem, você pode perguntar? Em primeiro lugar, ela torna a automação realmente simples. Basicamente, significa encontrar elementos no nosso aplicativo iOS através do inspetor e, em seguida, realizar operações sobre eles. Outra vantagem principal é a estrutura coerente do projecto que permite a qualquer pessoa navegar rapidamente através dele.

Vejamos um exemplo de uma aplicação que contém receitas. Ele mostra o livro de receitas padrão com receitas básicas na inicialização, que será a nossa primeira página. A partir daí, um usuário pode navegar para qualquer receita disponível, marcando assim uma segunda página. Além disso, o aplicativo também permite navegar por outros livros de receitas ou comprar livros premium, tornando-a a terceira página e, consequentemente – um arquivo objeto página.

Simplesmente, devemos criar arquivos de definição de passos correspondentes. Esta não é uma prática obrigatória, mas manter todas as definições de passos em um só lugar causa caos desnecessário.

Apesar de criar seus arquivos de classes de definição de páginas e passos é aconselhável escolher nomes que estejam relacionados à página (tela da aplicação) em que conteúdo você vai trabalhar. Nomear esses arquivos após uma característica ou cenário pode parecer certo à primeira vista, mas à medida que o projeto se expande, você vai notar mais e mais desordem em sua estrutura. A adoção da convenção de nomes de página garante que qualquer pessoa envolvida no projeto possa se familiarizar com ele imediatamente e começar a colaborar com ele em pouco tempo. Tal prática também contribui para a reusabilidade do código – seja de definições de passos ou métodos/funções.
Contrariamente aos arquivos de definição de passos e etapas mencionados, os arquivos de características do Pepino devem ser nomeados de acordo com uma característica que eles verificam. Inteligente, não é? E novamente, estruturando-os em diretórios nomeados em relação a um determinado campo da aplicação em teste, tornará a estrutura mais significativa.
O conceito básico da Seriedade é ser uma ‘documentação viva’. Portanto, dar cenários de teste e arquivos de recursos com nomes apropriados ajuda a equipe e as partes interessadas a entender melhor os relatórios e todo o projeto.

Outro ingrediente que expande os benefícios do modelo Page Object no projeto de automação de testes é PageFactory. É uma ferramenta que ajuda a reduzir o trabalho de codificação e facilmente colocar localizadores MobileElements em código, usando a notação @FindBy. A partir daí, encontrar elementos para o Appium interagir com eles em testes é muito mais simples.

Assertion

Executar testes via Appium pode consumir muito recursos. Para facilitar a sua máquina MacOS a executar testes no seu dispositivo iOS, certifique-se de que não está constantemente a afirmar a visibilidade de todos os objectos de uma página. Esta prática aumenta significativamente o tempo de execução dos testes, o que normalmente não é o mais desejável.

O que é mais, quando você tem que verificar se um elemento é visível, habilitado, clicável, ou qualquer coisa entre eles – tente evitar localizar elementos móveis usando o Xpath. A dica do inspetor Appium tem um ponto válido! Você deve fazer o que puder para convencer a equipe de desenvolvimento a fazer um esforço extra e atribuir IDs e nomes únicos aos elementos da aplicação. Isto não só tornará os testes de automação mais fáceis e rápidos, como também tornará o seu trabalho como testador mais eficaz, resultando em última análise no aumento da qualidade geral do produto. E é por isso que estamos aqui. Sem mencionar que a manutenção dos testes (por exemplo, mudar para diferentes localizadores quando necessário) se tornará muito mais agradável.

Entendendo os passos

Outro aspecto da configuração deste tipo de projeto se resume a aproveitar o Cucumber e usar a linguagem Gherkin.

Gherkin implementa uma abordagem direta com Given, When, Then notation com a ajuda do adicional And e But que parece bastante fácil de usar. Você pode escrever praticamente tudo o que quiser nos passos de teste dos seus arquivos de características. Em última análise, os métodos chamados vão executar ações.

Mas a razão para usar a abordagem Behavior Driven Development e o próprio Cucumber está permitindo que as pessoas não-técnicas envolvidas no projeto entendam o que está acontecendo no campo de testes. Não só isso, escrever cenários de testes em Given/When/Then manner também pode agir em sua vantagem. Tais descrições de testes de alto nível entregues pelo cliente ou pelo analista de negócios irão fazê-lo codificar em pouco tempo, desde que sejam escritas adequadamente. Aqui estão algumas dicas úteis:
Cenários de teste escritos em Gherkin devem focar no comportamento do aplicativo (daí Behavior Driven Development).
Aqui está um exemplo de como NÃO escrever cenários de teste em Gherkin, explorando melhor o tema da aplicação do livro de receitas:

Acima do exemplo ilustra duas más práticas que devemos evitar: Ele foca na implementação ao invés de no comportamento e usa valores codificados em vez de escrever passos de teste de forma a permitir a reusabilidade através da mudança de valores dentro de um passo.

Por isso, um cenário adequado para a compra de um livro de receitas no nosso exemplo de aplicação deve parecer:

Outro exemplo:

Adotar esta abordagem significa menos trabalho criando e codificando os passos do teste sempre que a implementação de uma característica em particular mudar.

Uma parte da notação principal de Given/When/Then, Cucumber suporta o uso de passos de conjunção. Usando E e Mas as notações de passos tornarão os passos do teste mais gerais e reutilizáveis, o que resulta em escrever menos código e manter a ordem dentro do projeto. Aqui está um exemplo básico:

Fazendo isso, se você codificar o passo acima ‘Given’ para localizar nosso elemento de receita procurando seu nome, você pode reutilizá-lo muitas vezes apenas mudando o valor da string no passo (desde que você codifique a definição do passo corretamente mais tarde). Além disso, o passo ‘E’ pode ser parte de qualquer cenário de teste que envolva tal ação.

Pondo tudo junto

Após configurar um projeto utilizando as práticas descritas acima, as partes mais visíveis do uso do Serenidade são os relatórios de teste gerados. Após adotar a tag @RunWith(CucumberWithSerenity.class) em seu arquivo de classe TestRunner, a execução da suíte de testes resultará na geração do Serenity de um relatório de resultados de teste agregado, que pode ser útil na avaliação da qualidade do aplicativo em teste e na apresentação do status do produto para os interessados ou para a equipe de desenvolvimento.

Appium, Cucumber, Serenity – Summary

Como você pode ver, o conceito de melhores práticas em testes de automação pode ser resumido em três palavras: reusabilidade, legibilidade e desempenho. Reutilização significa menos codificação, consequentemente diminuindo o tempo necessário para terminar o trabalho. A legibilidade melhora a compreensão, o que é crucial para garantir que o produto faça o que precisa fazer. Finalmente, o desempenho poupa o tempo de execução e melhora a estabilidade. Todos os três contribuem não só para a qualidade do projeto de automação de testes, mas têm um papel significativo na melhoria da qualidade geral do aplicativo entregue.