Lidando com testes mentirosos — Estabilizando os ofensores

Repostagem de 12/05/2010

Em Lidando com testes mentirosos eu falei sobre a pirâmide alimentícia e a necessidade de ter mais testes unitários e menos testes de sistema. Porém mesmo com menos testes de sistema é necessário que eles sejam estáveis. Nesse post vamos falar de alguns princípios para conseguir isso.

Foco em uma funcionalidade específica

É importante que os testes foquem em uma funcionalidade específica. Por exemplo, se estou escrevendo um teste de pesquisa de clientes, é necessário ter um cliente cadastrado. Como não estou testando o cadastro de cliente, posso fazer com que o teste salve manualmente o cliente através de uma chamada ao banco.

O foco em uma funcionalidade específica torna o teste mais rápido e ajuda no isolamento de problemas. No caso acima se o teste falhar sei que o problema foi com a pesquisa e não com o cadastro.

Além disso, essa abordagem permite que testes sejam escritos mesmo que o sistema todo não esteja implementado, quebrando dependência entre histórias. Normalmente dependências entre histórias causam problemas de priorização e planejamento.

Testes independentes

Os testes devem ser independentes uns dos outros. Isto é, não deve ser obrigatório rodar o teste A antes do teste B e nada que o teste A fizer pode influenciar no resultado de B. Essa premissa tem duas conseqüências:

• Cada teste deve preparar o ambiente necessário para sua execução. Ex. cadastrar clientes, pedidos, colocá-los em um status específico, etc.
• Cada teste deve deixar o ambiente inalterado, ou seja, qualquer operação que altere o estado do sistema (ex. operações no banco, alterações em arquivo) devem ser desfeitas no final. Isso permite os testes sejam executados em qualquer ordem e podem ser executados várias vezes tendo o mesmo resultado.

Tecnologia certa

Existem várias tecnologias disponíveis para testes de sistema. As tecnologias programáveis em alguma linguagem conhecida são melhores. Elas ganham em custo de manutenção, flexibilidade e estabilidade.

Não recomendo as tecnologias das categorias abaixo:

• Proprietárias: Elas não tem documentação e suporte da comunidade como as abertas. Pelo histórico, muitas deixaram de existir, deixando os seus usuários na mão, como o que ocorreu com alguns produtos da Mercury. Exemplos: QuickTest, Winrunner.
• Baseadas em record/playback: O código gerado normalmente é ruim e favorece testes instáveis. Caso o código gerado não seja revisto manualmente, haverá muita duplicação entre os testes. Exemplo: Selenium IDE.

Base de testes limpa

Confiança na base de teste é essencial para o sucesso de uma estratégia de automação.

É melhor ter poucos testes confiáveis do que muitos mentirosos. Se um teste está minando a confiança na sua base é melhor que ele não esteja lá, delete-o. É uma abordagem radical, mas que ajuda a manter uma base de testes limpa[1].

[1] Ver também Teoria das janelas quebrada