A seguir serão descritos antipadrões de automação para testes de unidade, de acordo com o esqueleto definido na Seção 5.4. Os indícios de problemas citados nos padrões possuem mais informações na Seção 5.2.
6.5.1 Gancho para os Testes (Test Hook) Tipo: Testabilidade
Contexto: Testar um sistema pode ser muito complexo, principalmente quando os módulos e objetos estão muito acoplados entre si, como é discutido na Seção 10.3. Quando não é possível substituir nem parte do comportamento do sistema através de Objetos Dublês, os testes podem se tornar inviáveis de serem realizados. Uma solução simples é modificar o próprio comportamento do sistema apenas para a execução dos testes, ou seja, é feito um gancho no sistema para torná-lo testável.
Apesar de simples, essa solução é ruim porque ela polui o código do sistema, tornando-o mais ex- tenso e complexo. Isso aumenta as chances do sistema conter erros, que vai completamente contra o objetivo dos testes automatizados. Não obstante, essa solução ainda pode inibir refatorações para melhorar o design do sistema.
Exemplo: A implementação típica é a criação de uma flag para indicar que são os testes que estão executando o sistema. Se forem os testes, então é executado o trecho de código substituto e testável do sistema, como é exibido na Figura 6.34.
1 // Antipadrão: Gancho para os Testes (Test Hook) 2 public class UmaClasseDoSistema {
3 public boolean TESTANDO = false;
4 // ...
5 public void umaFuncionalidadeComBaixaTestabilidade() {
6 if(TESTANDO) {
7 // Simule algo de forma isolada e controlada para os testes ...
8 }
9 else {
10 // Faça o que deve ser feito ... 11 }
12 }
13 // ... 14 }
Figura 6.34: Antipadrão Gancho para os Testes.
Indícios de Problemas Relacionados: Hard-to-Test Code, Test Logic in Production e Production Bugs (vide Seção 5.2).
Referências: Esse antipadrão foi identificado por Meszaros como um padrão [99]. No entanto, ele explica que essa abordagem deve ser utilizada apenas em casos excepcionais, quando é inviável refatorar o sistema para aumentar a testabilidade.
6.5.2 Testes Encadeados (Chained Tests) Tipo: Organizacional
Contexto: É normal que alguns casos de testes sejam parecidos e possuam trechos de código auxiliares em comum. Por isso, refatorações para diminuir a replicação de código-fonte deve ser uma tarefa rotineira durante a criação dos testes automatizados.
Uma situação comum, é que um caso de teste seja muito parecido com o método de set up de outro, isso porque os testes podem ser complementares. Uma possível solução para evitar replicação de código para este caso, é fazer com que ambos os testes compartilhem as mesmas variáveis e sejam executados em sequência, de forma encadeada.
Entretanto, essa solução incentiva o uso de informações compartilhadas entre os testes e, conse- quentemente, dependentes entre si, frágeis, difíceis de serem entendidos e mantidos. Além disso, essa abordagem pode até inviabilizar o uso de ferramentas que otimizam a bateria de testes como um todo, por meio de ferramentas que paralelizam a execução dos testes. Se uma funcionalidade é dependente de outra, pode-se utilizar Objetos Dublês para tornar os testes independentes. Exemplo/Java/TestNG: A Figura 6.35 mostra um exemplo de teste com a ferramenta TestNG que
possui funcionalidades para criar testes encadeados.
1 //Referências do TestNG
2 import org.testng.annotations.Test ;
3
4 public class UmaClasseDeTest {
5
6 @Test
7 public void teste1() {
8 }
9
10 // Antipadrão: Testes Encadeados (Chained Tests)
11 // Esse teste só será executado depois do que o teste1 tenha sido executado.
12 @Test(dependsOnMethods="teste1")
13 public void teste2() {
14 } 15 }
Figura 6.35: Um exemplo de esqueleto de código Java do antipadrão Testes Encadeados. Indícios de Problemas Relacionados: Obscure Test, Assertion Roulette, Erratic Test, Fragile Test,
Frequent Debugging, Slow Tests, Buggy Tests, High Test Maintenance Cost (vide Seção 5.2). Referências: Esse antipadrão foi identificado por Meszaros como um padrão [99]. Em casos excep-
cionais, esse antipadrão pode ser útil em testes de integração, mas desde que ele seja utilizado com cautela.
Capítulo 7
Testes com Persistência de Dados
Controlar e garantir a qualidade da camada de persistência de dados é fundamental, não apenas devido ao valor da informação, mas também porque dados inconsistentes podem afetar a correção das outras camadas do sistema [64].
Falhas com os dados podem desencadear uma infinidade de situações indeterminadas de erros no sistema que gerencia a camada de persistência. As camadas superiores ao módulo de dados são imple- mentadas para trabalhar com dados corretos, ou seja, não estão preparadas para lidar com situações onde os dados não seguem os formatos e as convenções definidas.
Quando esses erros são identificados antes da causa principal do problema, o processo de identifi- cação e correção das falhas se torna um trabalho ainda mais complexo e demorado. O próprio sistema, ou até mesmo o usuário final, pode ser induzido a criar novos dados problemáticos, o que, talvez, resulte em um ciclo automático de adição de erros e na perda da credibilidade dos dados armazenados.
Por causa da gravidade que os problemas nos dados podem ter, muitas empresas possuem depar- tamentos exclusivos de especialistas para implementar e gerenciar a camada de persistência de dados. Contudo, mesmo os especialistas na área e as ferramentas de persistência de dados não garantem que todas as situações propícias a erros sejam verificadas a cada alteração do sistema.
A camada de persistência pode possuir muitos pontos suscetíveis a falhas. Basicamente, a camada é composta por funcionalidades de escrita e leitura dos dados, que, geralmente, são implementadas com a ajuda de APIs e arcabouços, mas o uso destas ferramentas e a criação da lógica de leitura e escrita nem sempre são tarefas triviais.
Este capítulo irá descrever alguns padrões e técnicas de automação de testes para aumentar a produ- tividade e tornar os testes mais rápidos e robustos. Além disso, serão discutidos as situações típicas de cenários de testes tanto para sistema de arquivos quanto para bancos de dados.