O texto de hoje tem a intenção de explorar uma pergunta que vez ou outra escutamos de algum cliente. É comum ouvir frases do tipo: “Já enxerguei a importância de ter testes automatizados! Os testes 100% manuais estão sacrificando nosso tempo e a qualidade do release! Mas por onde a gente começa? Que tipo de testes usamos para começar a automatizar?”
Se interessou pelo assunto e está sem tempo para ler? Ouça agora!
Como preâmbulo, que bom que a necessidade de automatizar os testes já está clara! Não é nada razoável mantermos pessoas em nossos projetos com o propósito único de rodar testes de forma manual.
Esse trabalho pode ser automatizado com um grau de confiabilidade bem alto, liberando as pessoas (por exemplo, as pessoas da área de testes) para funções mais nobres e produtivas, como elaborar e executar testes exploratórios em casos ainda inexplorados ou não pensados:
- impedir que alguns campos aceitem datas como 29/fev em anos que não são bissextos (esse erro aqui é digno dos bons testadores! Não é qualquer um que pensa com esse tipo de maldade!);
- informações importantes que deveriam estar na tela mas não estão;
- erros de português em labels, mensagens etc;
- “corner-cases“;
- etc.
Testes automatizados: aceitação
É fato que existem vários tipos de testes automatizados que podem ser feitos: unitários, integração, funcionais, aceitação. Por onde começar a testar no seu sistema? 
Sem dúvida, por onde houver maior ROI (Return on Investiment) e, normalmente, nos casos de sistemas que já possuem algum tempo de desenvolvimento, esse ROI é maior se começarmos atacando pelos testes de aceitação. Por quê? Os testes de aceitação são por natureza testes caixa-preta, e são os testes que mais facilmente expressam o que o cliente gostaria de fazer ou ter no seu software.
Desta forma, tendem a ser altamente alinhados com as regras de negócio (expressas por exemplo através das Histórias de Usuário).
Como insumo para escrever os testes de aceitação, podemos (ou devemos!) usar os critérios de aceitação descrito pelos Product Owners nas histórias de usuário. Estando estes testes implementados, rodando e passando com sucesso, obteremos uma boa cobertura e garantia de que pelo menos as funcionalidades mais importantes estão sendo de fato cobertas pelos nossos testes.
O mais importante, todo esse feedback acontece em poucos minutos e sem necessidade de intervenção humana!
Esse tipo de teste pode/deve rodar em um robô de Integração Contínua (Jenkins, TravisCI, Hudson, CruiseControl etc) que fará o trabalho de rodar os testes por você, de acordo com alguma estratégia pre-definida (todo dia, a cada modificação feita no código-fonte etc.).
E como é a anatomia de um teste de aceitação?
Basicamente, este tipo de teste pode ou não usar uma pegada Comportamental (BDD), devem manipular a interface como se fosse um usuário (usando ferramentas como o Selenium WebDriver) e garantir o estado encontrado no banco de dados antes mesmo do teste rodar (para evitar testes vaga-lume, que as vezes passam e as vezes não passam).
Hoje em dia, conseguimos implementar este tipo de teste em praticamente todas as linguagens ditas “comerciais” (Java, Python, C#, Delphi , Ruby etc.). Claro que, por ser um teste caixa-preta, você saberá que há um problema mas não saberá em que camada exatamente do seu sistema o problema reside.
Testes desse tipo sinalizam um erro (o que é ótimo), mas deixarão a cargo dos desenvolvedores a tarefa de buscar o ponto exato do problema (o que pode ser chato, gerando necessidade de debugs enormes).
Costumo fazer a analogia de que testes de aceitação são ótimos “zoom out” do sistema, enquanto que testes unitários (caixa-branca) são ótimos em zoom-in do problema. Em resumo:
Uma última dica é que, salvo raras exceções, não vale a pena começar pelos testes unitários. É comum encontrarmos sistemas legados altamente acoplados e desenvolvidos sem a preocupação de serem “testáveis” unitariamente.
Testar unitariamente significa isolar todas as outras classes/componentes para que possamos testar unitariamente um determinado pedaço de nosso código. Como fazer isso se o software, muitas vezes, está parecendo um castelo de cartas? Definitivamente, não é a melhor estratégia.
Espero que tenham curtido o post e gostaríamos de ter feedback de vocês, leitores, para os próximos assuntos sobre testes que devemos abordar! Mande sua sugestão nos comentários!
Treinamentos Relacionados
Leia mais sobre Testes Automatizados
- Como garantir a qualidade do software: Testes automatizados
- Testes Automatizados – O que a falta deles pode causar?
- Dívida Técnica e Juros Compostos
- Liquidando Dívidas Técnicas
