Teste de Software
Test Smells
Prof. André Hora
DCC/UFMG
Code Smells (ou Bad Smells)
● Parte do código (classe, método, etc) que não está
"cheirando bem"; logo, talvez precise ser refatorada
● Indicadores de código de baixa qualidade, isto é, difícil de
manter, entender, modificar, reusar, etc
● "Indicadores": decisão de refatoração não é imediata, mas
depende de uma análise e reflexão por parte dos devs
● Livro do Fowler: Capítulo 3 inclui um catálogo de code smells
2
Exemplos de Code Smells…
● Código Duplicado
● Métodos Longos
● Classes Grandes
● Métodos com Muitos Parâmetros
3
Test Smells
• Representam estruturas e características
preocupantes no código de testes de unidade, que
devem ser evitadas
• Adaptação do conceito de Code Smells para o
contexto de testes
4
5
Test Smells
• Test Smells não deve ser interpretado ao pé da letra
• Devem ser considerados como um alerta para os
implementadores do teste
• Assim como ocorre com código de produção, testes
devem ser frequentemente refatorados, para que
permaneçam simples, fácil de entender
6
Exercício
• Elabore dois test smells
• Para cada test smell, apresente seu nome e o
principal problema associado a este smell
7
Catálogo
8
Test Smells
• Assertion Roulette • Lazy Test
• Conditional Test Logic • Magic Number Test
• Constructor Initialization • Mystery Guest
• Default Test Duplicate • Redundant Print
• Assert Eager • Redundant Assertion
• Test Empty • Resource Optimism
• Test Exception Handling • Sensitive Equality
• General Fixture • Sleepy Test
• Ignored Test • Unknown Test
9
Conditional Test Logic
• Métodos de teste devem ser simples e executar todo
código do SUT
• Estruturas de controle nos testes podem alterar o
comportamento do teste e da saída esperada
• Sucesso e falha do teste é baseado nas asserções
que estão dentro de estruturas de controle
• Resultado do teste não é previsível
• Di culta a compreensão e manutenção do teste
10
fi
11
12
13
Exception Handling
• Ocorre quando o sucesso ou falha do teste
depende do lançamento de uma exceção no SUT
• O dev. deve utilizar o framework de teste para lidar
com lançamento de exceção no SUT
• Idealmente, o teste pode ser dividido em múltiplos
testes que (1) geram e (2) não geram exceção
14
15
16
17
General Fixture
• Ocorre quando a xture do teste é muito genérica e
os métodos de teste só acessam parte dela
• Uma xture que inicializa variáveis que não são
utilizadas nos testes indica sua generalização
• O ponto negativo: recursos estão sendo alocado
sem serem utilizados pelos testes
18
fi
fi
19
20
21
22
Mystery Guest
• Teste que utiliza recursos externos (arquivos, BD, etc.)
• Uso de recursos externo pode tornar o teste lento e
instável ( aky)
• Faz sentido para testes de unidade apenas
23
fl
24
Redundant Print
• Prints não são necessários pois os testes fazem parte de
um processo automatizado, sem intervenção humana
• Testes são auto-veri cáveis (self-checking - FIRST)
• O resultado de um teste deve ser facilmente veri cável
• Para interpretar o resultado do teste, dev. não deve abrir e
analisar um arquivo de saída ou fornecer dados manualmente
• O resultado dos testes deve ser binário
25
fi
fi
26
Unknown Test
• Ocorre quando um teste não contém asserts
• Neste caso, os testes sempre irão passar (se o teste não
lançar uma exceção)
• Testes sem assert não fazem sentido uma vez que não
sabemos o resultado esperado nem o que está sendo testado
• Smoke test?
27
28
Ferramentas
• Test Smell Detector: https://testsmells.org/index.html
• PyNose: https://github.com/jetbrains-research/pynose
29
