Get best of the week

4 melhores padrões de design para testes automatizados (e 86 mais)

Olá a todos. Antecipando o início do curso, o “Python QA Engineer” preparou uma tradução de outro material interessante.



A maior parte do sucesso de seus projetos de automação está na reutilização de padrões de teste conhecidos, que, como já comprovados, ajudam a aumentar a confiabilidade dos cenários de automação.

Um padrão de design de teste automatizado é uma solução simples que comprova sua eficácia para o mundo dia a dia. Esses modelos também são considerados práticas recomendadas para qualquer projeto criado com programação orientada a objetos.

Por que os padrões de design são tão importantes para testes automatizados?

Tome como certo que seus aplicativos mudarão com o tempo.
E como você sabe que as mudanças acontecerão de uma maneira ou de outra, você deve usar as melhores práticas e os padrões de design desde o início. Eles tornarão seus testes reutilizáveis ​​e fáceis de manter.

Aqui estão alguns padrões comuns de design de teste automatizado que muitas equipes usam para criar uma automação robusta de teste e melhorar toda a lógica de teste.

Objetos de página



Um exemplo de Objeto de Página de Nikolay Advolodkin do Automation Guild 2017

Uma das estratégias populares usadas no teste de automação é modelar o comportamento do seu aplicativo.
Para fazer isso, você pode usar objetos de página simples que simulam os pedaços de software que você está testando.
Por exemplo, você pode escrever um objeto de página para uma página de login ou home page. Essa abordagem reflete corretamente o princípio da responsabilidade compartilhada.

Se algo mudar, digamos, o ID do elemento, você precisará alterar apenas um local no código, e todos os testes usando esse objeto de página receberão automaticamente essa alteração sem ações desnecessárias. O código de teste deve ser atualizado apenas em um local. Essa abordagem também ajuda a reduzir a duplicação de código.

Os objetos de página também ocultam os detalhes técnicos de HTML e CSS por trás de métodos com nomes simples e claros.
A atenção à nomeação de seus métodos tem a vantagem adicional de ajudar a criar uma API de interface de programação de aplicativos agradável e legível que um programador menos tecnicamente experiente pode começar a usar rapidamente.

Esse padrão também segue a prática popular de desenvolvimento de software DRY (não se repita, não repita).
Basicamente, o princípio DRY significa que, para cada parte da lógica, um pedaço de código e não mais deve ser responsável. A duplicação no código dificulta a manutenção; quanto menos código você escrever, melhor, pois um código mais suportado significa mais chances de um erro surgir na sua estrutura de teste.

Somente este modelo de design de software pode resolver facilmente a maior parte dos seus problemas de teste, mas também não é uma panacéia. No entanto, permitirá dar um grande passo à frente, tornando seus testes funcionais automatizados mais estáveis.
Alguns testadores argumentam que o padrão Objeto de Página geralmente viola o princípio de que uma classe deve ter apenas um motivo para mudar.

Para evitar isso, muitos recorrem ao script, que foi descrito pela primeira vez por Anthony Marcano ( @AntonyMarcano) com a participação de Andy Palmer ( @AndyPalmer), Jan Molak ( @JanMolak) e outros.

Padrão de Roteiro


Os objetos de página são uma boa maneira de começar a tornar seus testes sustentáveis, mas se você não tomar cuidado, eles ainda podem ficar fora de controle com o tempo.
O padrão de roteiro (uma vez conhecido como padrão de jornada) é uma aplicação dos princípios de design do SOLID para testes de aceitação automatizados e ajuda as equipes a resolver esses problemas. Na verdade, foi isso que resultou da refatoração implacável dos objetos de página usando os princípios de design do SOLID.

O padrão de roteiro pega objetos de página e os divide em pedaços realmente minúsculos. Alguns testadores dizem que isso tornou seus testes mais fáceis de manter e confiáveis.
Outra vantagem significativa é que torna os scripts de teste mais legíveis.

A primeira vez que ouvi falar sobre o padrão de roteiro na sessão do Automation Guild em 2017 foi de John Smart (o @Wakeleo)criador de uma das minhas estruturas favoritas de automação de testes, Serenity . O
roteiro usa a ideia de atores, tarefas e objetivos para descrever formalmente os testes, recusando os termos de interação com o sistema. Roteiro, você descreve os testes em termos de um ator que tem objetivos.

Aqui está um exemplo:


Um exemplo da implementação do padrão de Roteiro da Automation Guild Session 2017 por John Smart

À primeira vista, pode parecer que usar esse padrão seja muito mais difícil que o mesmo Objeto de Página, mas John mencionou que usar essa abordagem economiza muito tempo as equipes com as quais trabalhava, reduzindo o custo de manutenção e suporte.

Portas e adaptadores


A arquitetura de portas e adaptadores visa garantir que você use o princípio da responsabilidade única , ou seja, um objeto específico deve fazer uma coisa e ter apenas um motivo para a mudança.
Ao usá-lo na automação, não se esqueça de separar o código do caso de teste de todo o resto para poder trocar componentes lentos e simuladores rápidos, permitindo executar o teste e o aplicativo em teste em um processo.

Livre-se das redes e E / S para que nada diminua a velocidade do conjunto de testes. Obviamente, isso não é fácil, mas quanto mais você se esforça para criar a automação da interface do usuário, melhor será para você.

Aprendi sobre esse padrão durante uma entrevista com o criador do Cucumber , Aslak Hellesoy ( @aslak_hellesoy)ele o descreveu como uma estratégia para obter feedback rápido dos testes completos do Cucumber. O

Aslak também recomendou um recurso chamado Todo-subsecond , que eu adicionei ao meu post . Engenheiros de automação de teste : este pequeno aplicativo com testes de aceitação de pilha completa que podem ser concluídos em milissegundos foi projetado para ilustrar os métodos básicos para alcançar isso em qualquer sistema.Depois de concluir uma série de exercícios, você aprenderá uma maneira especial de implementar desenvolvimento orientado ao comportamento.

Apresentador primeiro


O Presenter First é uma modificação do MVC (Model-View-Controller) para organizar o código e o desenvolvimento para criar software totalmente testado usando uma abordagem de desenvolvimento orientada a testes (TDD).
Eu aprendi sobre esse padrão pela primeira vez em uma entrevista com Sab Rose (@SebRose), um dos colaboradores do projeto Cucumber e autor do Cucumber for Java.
Ele disse que se você desenhar o padrão MVC na forma de blocos e setas, verá que a visualização, que é sua interface de usuário, tem conexões claramente definidas com o modelo e o controlador. Se em tempo de execução você puder substituí-los por modelos e controladores que seu teste cria e controla, não haverá motivo para que você não possa verificar se a interface do usuário não se comporta da maneira que deseja.

Você também pode personalizar seu modelo e controlador para simular todo tipo de comportamento estranho, por exemplo, falha na rede.

86 outros padrões de teste automatizados


Escrevi este artigo há muitos meses, mas nunca o publiquei.
Eu estava confiante na minha lista até falar com Seretta Gamba , autora do novo livro A Journey through Test Automation Patterns , onde ela e sua co-autora Dorothy Graham conversam sobre 86 padrões!

Eles dividem os padrões em quatro categorias distintas: padrões de processo, padrões de controle, padrões de design e padrões de execução.
Os que descrevi referem-se a padrões de design, mas existem muitos outros padrões que resolvem problemas não apenas com o código.

Por exemplo, existem padrões relacionados à cultura corporativa e aos modelos de governança deficientes que, na minha experiência, tendem a anular todos os esforços para automatizar os testes.
Para obter uma lista completa, consulte o wiki do padrão de design ou solicite um livro na Amazon.

Saiba mais sobre o curso.

More articles:


All Articles