Refatoramento e Testes

Roberta Coelho
Disciplina: Teste de Software II
O que é refatoramento/refactoring?
Definição por Kent Beck

“A change to the system that leaves its behavior

unchanged, but enhances some nonfunctional
quality – simplicity, flexibility, understandability,
performance”

(Kent Beck, Extreme Programming

Explained, page 179)
Definição por Fowler

“A change made to the internal structure of

software to make it easier to understand
and cheaper to modify without changing
its observable behavior”

(Martin Fowler, Refactoring, page 53)

Fowler’s Book
Code Smells / Mal cheiro

• Indicadores de que algo pode estar

errado no código

• Pode ocorrer em código de produção ou

testes
Code Smells (Fowler)
1. Alternative Classes with
Different Interfaces
2. Comments
3. Data Class
4. Data Clumps
5. Divergent Change
6. Duplicated Code
7. Feature Envy
8. Inappropriate Intimacy
9. Incomplete Library Class
10.Large Class
11.Lazy Class
12.Long Method
13.Long Parameter List
14.Message Chains
15.Middle Man
16.Parallel Inheritance
Hierarchies
17.Primitive Obsession
18.Refused Bequest
19.Shotgun Surgery
20.Speculative Generality
21.Switch Statements
22.Temporary Field
Lista
Definição conjunta

Mudanças no código que

– Não afetam o comportamento (todos os testes
passam)
– Removem duplicidade e complexidade desnecessária
– Melhora a qualidade
– Torna o código mais simples e fácil de entender
– Deixam o código mais flexível
– Deixam o código mais fácil de mudar/manter
Por que refatorar?

• Previne “design decay”

• Limpa a “bagunça” do código
• Simplefica o código
• Melhora leginilidade e compreensão
• Encontra bugs
• Reduz o tempo de Debug
• Auxilia no entendimento da aplicação
• Refazer as coisas é fundamental em todo
processo criativo – a segunda vez geralmente sai
melhor….
Como refatorar

• Ter certeza que todos testes passam

• Encontrar “bad smells” no código
• Determinar como simplificar
• Aplicar simpleficações
• Re-executar os testes e garantir que todos
passam
• Repetir o ciclo
Fluxo de trabalho

Todos testes encontrar Definir

passam bad smells simplificação

Garantir que Realizar

Todos testes simplificação
passam
Refactoring Test Code
Motivação

“If there is a technique at the heart of extreme

programming (XP), it is unit testing” [1]

[1] Kent Beck, Embracing change with extreme

programming. IEEE Computer, 32(10):70–77, 1999.
Motivação

• Em um framework como o JUnit…

• Um teste típico inclui:

1) código para set up dos dados usados para teste,
2) chamada do método sendo testado,
3) comparação entre valores atuais e esperados
4) código para “limpar” (tear down) consequências
do teste.
Motivação

• Metodologias ágeis encorajam a escrita de uma

classe de testes para cada classe do sistema.

• Taxa ideal:
– test code / production code =~ 1:1

• Assim não é uma surpresa que código de testes

também precise ser refatorado.
Motivation

• Refatorar o código de testes é diferente de

refatorar código de produção:

(1) Existem refatoramentos adicionais para o

código de testes: test-specific refactorings.
Code smells (van Deursen, et al.)

• Mystery Guest • Assertion Roulette

• Resource Optimism • Indirect Testing
• Test Run War • For Testers Only
• General Fixture • Sensitive Equality
• Eager Test • Test Code Duplication
• Lazy Test
Code Smell: Convidado Misterioso

• Testes que usam recursos externos

• Os testes não são auto-contidos:
– Ex: usar um arquivo que armazena os dados de teste
• Dificulta entendimento
• Introduz dependências “escondidas”
Code Smell: Convidado Misterioso

• Testes que usam recursos externos

• Os testes não são auto-contidos:
– Ex: usar um arquivo que armazena os dados de teste
• Dificulta entendimento
• Introduz dependências “escondidas”

• Refactorings
– Inline Resource
– Setup External Resource
Code Smell: Roleta de Assertivas

• Múltiplas assertivas em um único método de

testes sem explicações

• Refactorings
– Adicionar explicação
Code Smell: Igualdade Sensível

• Métodos de checagem que são afetados por

características “não essenciais” do
comportamento
• Ex: Usar toString pode afetar os testes após uma
mudança na pontuação.
Code Smell: : Igualdade Sensível

• Métodos de checagem que são afetados por

características “não essenciais” do
comportamento
• Ex: Usar toString pode afetar os testes após uma
mudança na pontuação.

• Refactorings
– Introduzir métodos de igualdade.
Code Smell: Teste Guloso

• Um único teste checa vários métodos do objeto

sendo testado
Code Smell: Teste Guloso

• É difícil de ler e entender, desta forma mais difícil

de usar como documentação.

• Torna testes mais dependentes uns dos outros.

• Mais diícil de manter.

• Refactorings
– Extract Method
Code Smell: Apenas para Testadores

• Métodos que existem em código de produção

apenas para facilitar os testes.

• Dependendo da funcionalidade destes métodos,

você pode não querer que permaneçam no
código de produção:
– onde qualquer desenvolvedor pode usar...
Code Smell: Apenas para Testadores

• Métodos que existem em código de produção

apenas para facilitar os testes.

• Dependendo da funcionalidade destes métodos,

você pode não querer que permaneçam no
código de produção:
– onde qualquer desenvolvedor pode usar...

• Refactorings
– Extract Subclass
Code Smell: Apenas para Testadores

• O medo deste smell pode levar a uma solução

indesejada  uma classe sem o correspondente
método de testes.

• Razões:
1. O desenvolvedor não sabe testar a classe sem adicionar
métodos.
2. O desenvolvedor não quer “poluir” o código com
métodos de teste.
Qual a solução então???
Qual a solução então???

Criar a subclasse e incluir no /test

Code Smell: Setup Geral Demais

• No JUnit:
– O programador pode escrever setUp method que
será executado antes de cada método de testes.
– Ele cria o que chamamos de “fixture” para os testes
que rodarão.

• O código começa a “cheirar mal” quando o fixture

é geral e diferentes métodos só usam parte dele.
Code Smell: Setup Geral Demais

• No JUnit:
– O programador pode escrever setUp method que será
executado antes de cada método de testes.
– Ele cria o que chamamos de “fixture” para os testes que
rodarão.

• O código começa a “cheirar mal” quando o fixture

é geral e diferentes métodos só usam parte dele.

• Refactorings
– Extract Method
– Inline Method
– Extract Class
Code Smell: Teste Indireto

• Classe de testes que testa outros objetos que não

aquele que é o foco da classe de testes

• Refactorings
– Extract Method
– Move Method
Code Smell: Otimismo sobre Recursos

• Testes fazem suposições otimistas sobre a

existência ou estado de recursos externos ou
atributos.

• Refactorings
– Criar setup Exemplo???
Code Smell: Código de Teste Duplicado

• Código repetido em vários métodos de teste.

• Refactorings
– Extract Method
Para concluir

• Vimos alguns code smells:

– Auxiliam a identificar “pontos de melhoria” do
código de testes.
Para concluir

• Para cada “mal cheiro” soluções são dadas:

– Usando uma variante de um refatoramento
existente (Fowler) ou
– Uma solução específica para o código de testes.