No ultimo dia 24 palestrei no terceiro encontro do grupo XPCE sobre automação de testes funcionais com Selenium. Estes foram os slides da palestra:

Em breve colocarei o projeto usado como exemplo.

Oi pessoal, nesse primeiro post vou falar de testes automatizados. Quem me conhece sabe que esse é um assunto que me interessa muito, mas desta vez o assunto não é teste de unidade, e sim testes funcionais, muitas vezes chamados de teste de aceitação.

A realização de testes funcionais é uma prática bem mais difundida do que testes de unidade. É uma disciplina presente em qualquer metodologia de desenvolvimento, até mesmo porque o cliente em algum momento do ciclo de vida do projeto vai querer verificar se o que foi desenvolvido satisfaz suas espectativas.

O que não é uma prática difundida é a automatização dos testes funcionais e sua utilização desde as fases iniciais do desenvolvimento. Enquanto testes de unidade vem ganhando atenção, principalmente com a popularização de metodologias ágeis como XP, a automatização de testes funcionais, também defendida por esta metodologia, não tem ganho a mesma atenção.

Em vários projetos já vi diversos motivos para o não investimento na automatização. O mais comum, infelizmente, é nem sentir sua falta. Se se trabalha com um processo cascata, a fase de teste só é realizada uma vez (no final do projeto) e não existe muito overhead para ser eliminado. Nesses projetos a equipe geralmente tem tantos pepinos que qualidade de software chega a ser um luxo.

Em outros, a preocupação com qualidade do software parte de quem realmente bota a mão na massa: os desenvolvedores. Estes, por estarem muito envolvidos com aspectos de baixo nível, se preocupam em testar o código e delegam, de certa forma, o teste a nível de usuário para a “equipe de teste” ou para o cliente mesmo. Pelo menos era assim que eu agia.

Mesmo sem a preocupação com a automatização de testes funcionais, estava tudo funcionando perfeitamente. O investimento em testes de unidade estava dando um ótimo retorno e, aliado a algumas outras práticas,  fazia com que as iterações terminassem em sua maioria sem nenhum bug e com o cliente bastante satisfeito. Porém, os sistemas em que trabalhei com essa abordagem tinham algo em comum: os testes de unidade eram feitos a partir do dia zero.

A frustração veio quando, ao entrar em um projeto em andamento e com alto índice de instabilidade, testes de unidade não mostraram ser uma boa ferramenta para começar a resolver o problema. Neste projeto as entregas não eram confiáveis. O sistema tinha muitos bugs e, a medida que eles eram corrigidos, outros apareciam ou retornavam. Intuitivamente, para identificar os bugs e evitar que eles voltem, pensamos em adotar testes de unidade. Porém não obtivemos a resposta esperada.

A causa era simples: Uma grande vantagem dos testes de unidade é a exposição de locais em que o design do código poderia ser melhorado. Dessa forma, ao implementar os testes de forma tardia, você vai achar diversos pontos em que o sistema precisa de uma refatoração. Mas como realizar as refatorações necessárias se a cobertura dos testes ainda está bem pequena e não te dá garantia que não vai quebrar o sistema?

É aí que entra a automatização dos testes funcionais. Por ser um teste completamente caixa preta, você pode de maneira bem mais rápida alcançar uma boa cobertura dos testes. Daí em diante você vai se sentir mais seguro para fazer as refatorações necessárias, de preferência já encaixando os testes de unidade também. Além, claro, do ganho óbvio na identificação de erros no sistema.

Pretendo em outros posts falar mais da automatização de testes funcionais. Nesse primeiro momento queria somente destacar sua importância, principalmente para sistemas legados. Posteriormente espero escrever sobre quais ferramentas e práticas estamos utilizando, além da dificuldade e benefícios encontrados.

Functional tests are the first type of tests any application should have. If you had to choose between writing unit tests or functional tests, you should choose the latter.

Junit in Action