Computadores são bons em fazer trabalhos repetitivos e a execução de testes é quase sempre um trabalho repetitivo. Logo, testes automatizados (automação de testes) se tornam fundamentais para garantir a qualidade do software.
“… Computadores são desenvolvidos para fazer trabalhos repetitivos. Quando você faz trabalhos repetitivos, os computadores se juntam para rir de você…” (Neil Ford)
Sem tempo para ler o artigo? Dê o play e escute agora!
A automação permitirá que você escreva o teste uma única vez e depois, de tempos em tempos, um robô executará todos os testes que você escreveu para o seu software.
O seu time ganha confiança porque a automação cria uma espécie de rede de proteção evitando que resultados inesperados se propaguem, dando a possibilidade do time resolvê-los antes que cheguem nas mãos dos clientes. Os testes ficam mais baratos e seu cliente mais satisfeito por não encontrar erros no seu produto.
Nos itens abaixo, falaremos sobre como os testes podem ser organizados e quais as ferramentas, frameworks e bibliotecas você poderá utilizar para começar a automação.
A Pirâmide de Automação de Testes
Podemos separar testes automatizados em três grandes blocos que formam a Pirâmide de Automação de Testes.
Testes unitários
Na base, temos os testes unitários. Eles são muitos, pois geralmente são fáceis de construir e baratos de manter. Um ponto interessante que percebemos na nossa jornada é que a definição de Unitário é diferente para cada empresa. Algumas colocam como a unidade do sistema (software completo), outros como um módulo ou um serviço.
Aqui adotamos o conceito de Kent Beck e Martin Fowler: A unidade do código é menor parte do programa que contém código-fonte.
A origem do nome vem do Delphi que armazena o código em uma Unit. Para o Java, C#, Python, Ruby é a classe.
Ferramentas para isso são muitas. Dependendo da linguagem de programação que você esteja usando. Abaixo uma pequena lista das ferramentas básicas para você começar a fazer testes unitários nos seus produtos.
| Linguagem | Ferramenta |
| Java | JUnit |
| .Net | Visual Studio Unit Testing Framework |
| Javascript | Unit.js |
| PHP | PHPUnit |
| Python | PyUnit (unittest) |
Outras práticas como Mock, Linguagem natural, matchers também devem ser utilizadas. Qualquer dúvida é só postar nos comentários.
Integração
No meio da pirâmide temos os testes de integração. São aqueles que atravessam a unidade do código-fonte. Como por exemplo, a comunicação entre duas ou mais classes através de um método, ou a comunicação do software com o banco de dados e até mesmo outros serviços.
Estes testes costumam a ser um pouco mais caros para manter, pois há dependência entre dois ou mais componentes. A alteração de um pode influenciar no teste do outro. Além disso, se o seu teste depender de uma massa de dados de entrada, você deverá prepará-la antes dos testes e retornar o seu banco de dados ao estado original após o teste. O uso de Mocks pode reduzir significativamente essa interdependência.
As ferramentas que são utilizadas para esses testes são basicamente as mesmas indicadas nos testes unitários. Todavia, aqui podem ser utilizadas outras como Postman para integração com APIs (serviços e micros serviços), DB Unit para integração com banco de dados, entre outras.
Interface e Aceitação
No topo da pirâmide temos os testes de interface e aceitação. Eles são mais difíceis de serem construídos e mais caros de serem mantidos, porque precisamos de toda uma preparação para rodá-los. São testes caixa-preta que executam a jornada completa do usuário interagindo com o software.
Aqui as ferramentas mais comuns para automatização são:
Testes de interface
| Ambiente | Ferramenta |
| Web | Selenium |
| Android | Espresso |
| iOS | XCode UI Tests |
| Windows | Visual Studio Coded UI Test |
Testes de Aceitação
| Linguagem | Ferramenta |
| Java | Cucumber |
| .Net | SpecFlow |
| Javascript | Jasmine |
| PHP | PHPSpec |
| Python | Behave |
Testes manuais
Além dos testes automatizados, acima da pirâmide, eu gosto de acrescentar o olho que tudo vê que representa os testes manuais. Eles dependem totalmente da intervenção humana desde a preparação da base de dados, são muito caros de serem construídos e mantidos. Todavia são importantes para avaliar a experiência do usuário. Eles são um teste adicional e não podem servir como a única coisa disponível.
Testes não funcionais
Além dos testes funcionais, você pode e deve fazer a automação de testes não funcionais para garantir que seu produto cumprirá o propósito para o qual foi desenvolvido. Um teste desse tipo que eu utilizei bastante foi o teste de carga e performance com o Apache JMeter.
Já para a execução de testes de segurança, uma ferramenta que eu gosto bastante é o OWASP Zed Attack Proxy (ZAP). Ele possui um Spider que realiza o scan no endereço do seu site e também consegue fazer navegação forçada caso o seu produto precise de login e senha de acesso.
Agora que já vimos quais são os tipos de testes automatizados, vamos ver…
Quando os testes automatizados são executados?
O tempo todo, ou quantas vezes o time achar necessário. Na verdade, os servidores de Integração Contínua como o Jenkins ou TravisCI ficam verificando o seu repositório de controle de versão (Git, Subversion, Mercurial, etc.) em intervalo de tempos regulares e podem executar toda a bateria de testes quando detectarem que algum arquivo foi modificado.
Se você tem 10.000 testes, ele pode executar todos os testes a cada rodada alteração de código. Você também pode decidir se os testes mais lentos serão feitos algumas poucas vezes ao dia tipo nightly build (construção noturna). Esses robôs são extremamente configuráveis e você decide até onde o pipeline da construção vai. Por exemplo:
- Checkout
- Compilação e Construção
- Testes Unitários e Integração
- Testes de Interface e Aceitação
- Testes de Carga
- Publicação Resultado dos testes
- Disponibilização em Homologação
- Aprovação
- Disponibilização em Produção
Como eu sei o quão seguro estou com os meus testes?
A maioria dos servidores de Integração contínua possuem ferramentas que avaliam a Cobertura de Testes e indicam qual o tamanho da sua rede de proteção. O Jenkins tem o Cobertura Plugin que mostra quanto o produto está testado.
E até mesmo quais linhas de código estão ou não cobertas por testes automatizados.
Há outras ferramentas como Clover e SonarQube que dão não só a cobertura do código, como também avaliam práticas de Clean Code, dívidas técnicas, bugs potenciais, etc.
Beleza! Vou colocar meu código 100% coberto
Nem tanto ao mar e nem tanto a terra. Não ter nada automatizado é ruim, mas ter 100% de automação pode não ser bom. Por exemplo, se você usa uma linguagem mais verborrágica como Java, qual o valor de automatizar todos os gets e sets da aplicação? Escolha o que você quer testar. Uma estratégia que os times que eu estive adotam é separar a aplicação em pacotes de especialidade e alguns pacotes tinham 100% de cobertura de testes e outros eram negociáveis. Os que tinham 100% de cobertura eram:
- Regras de Negócio
- Filtros de Dados
- Serviços e Micro serviços
- Controladores
- Utilitários
Outros como pacotes de classes de modelo, acesso a dados, enumeração e visão eram negociáveis. Dependia do produto, utilidade da classe, etc.
Conclusão
Automatizar é preciso, caso contrário a qualidade do seu software será baseada em muito achismo e muita documentação e ineficiência. Espero que este artigo tenha ajudado a ter uma ideia por onde começar e qualquer dúvida, poste nos comentários.
Não confie em documentação. Documento não compila (incluído nesta fase planilhas, softwares bonitinhos que registram texto todo estilizado).
Veja mais sobre esse assunto
Que tal ir num treinamento 100% prático sobre automação de testes? Veja nosso treinamento de Testes Automatizados.
Se além de Testes Automatizados, você também quer entender o que é DevOps e aprender algumas práticas e ferramentas para automatizar não só seu desenvolvimento, como também sua infraestrutura, confira nosso treinamento de Certified Scrum Developer (CSD).
Veja outros posts sobre Testes Automatizados:
