TDD e Refactoring

TDD e Refactoring
André Luís Pitombeira
Saturday, May 25, 13

Quem sou eu?
• Bacharel em Sistemas de Informação (UFC/
Quixadá)
• Bacharel em Administração de Empresas (FCRS)
• Desenvolvedor de Software do lsbd

Quem são vocês?
• Respondam estas três perguntas
• Qual o seu nome?
• O que você faz da vida?
• O que você espera deste curso?

Objetivos
• Deﬁnir os principais conceitos relacionados ao
TDD e Refactoring
• Mostrar boas práticas de programação e design de
sistemas
• Demonstrar o uso de algumas ferramentas

Programação
• Primeira parte
• Test-Driven Development (TDD)
• Segunda parte
• Refactoring

Test-Driven Development (Parte I)

Agenda
• Motivação
• Famílias e tipos de testes
• Teste unitário
• Test-Driven Development
• Exercício de ﬁxação

O problema
Barato Rápido
Bom

No silver bullet!

Porém, com testes...
• Um pouco mais rápido
• Um pouco mais barato
• Um pouco melhor

Rápido
0
250
500
750
1000
Projeto Implementação QA Post-release
Tempo gasto para resolver bugs

Barato
• Bugs são descobertos nas fases iniciais do
desenvolvimento
• Custo para resolver bug = Número de bugs /
Custo por bug resolvido
• Custo dos testes = Número de features /
Complexidade das features

Melhor
• Desenvolvimento tradicional
• Instintivo
• Difícil de mensurar
• TDD
• Indicativo
• Mensurável
• Testável

Então, a solução é testar

Mas por que os desenvolvedores
deveriam escrever testes?
• Respostas comuns
• Deixa os testes para o QA
• Desenvolvedores são muito ocupados
• Desenvolvedores não sabem como testar
• Nós não temos bugs
• Desenvolvedores não são adequados para testar
o código

Os desenvolvedores deveriam
considerar isto...
• Como os desenvolvedores vão saber que estão
fazendo software de qualidade sem os testes?
• Testes são uma ferramenta para ajudar os
desenvolvedores a contribuírem para qualidade
• Testes ajudam a dar perquenos passos e receber
feedback constante
• Testes ajudam a manter o foco sobre
mensuráveis resultados de desenvolvimento

Panorama da indústria
• Principais problemas relatados na adoção de
testes pela indústria
• Aumenta o tempo de desenvolvimento
• Experiência ou habilidade insuficiente
• Insuficiente design
• Insuficiente aderência ao TDD
• Falta de ferramentas

O que é um teste de software?

“O teste de software é a
investigação do software a ﬁm
de fornecer informações sobre
sua qualidade em relação ao
contexto em que ele deve
operar. Isto inclui o processo de
utilizar o produto para
encontrar seus defeitos.”
Wikipedia

O que é qualidade de software?

“A qualidade de software é uma
área de conhecimento da
engenharia de software que
objetiva garantir a qualidade do
software através da deﬁnição e
normatização de processos de
desenvolvimento.” Wikipedia

Tipos de teste (Alguns)
• Teste funcional
• Teste de usabilidade
• Teste de stress
• Teste de aceitação
• Teste de regressão
• Teste de conﬁguração
• Teste unitário

Famílias de Teste
• XUnit (JUnit, PyUnit, JsUnit)
• “assert”
• TAP (libtap)
• “ok” ou “is”

Teste unitário
“Teste unitário é o método pelo qual unidades de
código são testadas para veriﬁcar se estas estão aptas
para o uso. Uma unidade é a menor parte testável de
uma aplicação.” Wikepedia

Por que teste unitário?
• Debugar é um processo que consume tempo
• Quando novas funcionalidades são adicionadas,
como assegurar que as antigas não quebraram?
• Ver a classe em ação
• Medida de qualidade de software

Teste unitário é bom se...
• É realmente automático
• Testa tudo que é provável quebrar
• Deve ser independente de ambiente e de outros
testes
• Deve ser repetitivo e mostrar sempre o mesmo
resultado toda vez que executar
• O teste deve ser claro

Exemplo de teste unitário
public void marriageIsSimmetric(){
Customer alice = new Customer();
Customer bob = new Customer();
bob.marry(alice);
assertTrue(bob.ismariedTo(alice));
assertTrue(alice.ismariedTo(bob));
}

hands-on!

O que é TDD?
• Uma técnica iterativa para desenvolver software
• Escreva primeiro um teste que falha(ou até mesmo
não compile), antes de escrever uma nova
funcionalidade
• O objetivo do TDD é especiﬁcação e não validação
• Uma prática para evoluir o código eﬁcientemente

Ciclo do desenvolvimento com TDD

Regras fundamentais do TDD
• Escreva somente o código suﬁciente para o teste
passar
• Escreva testes pequenos
• Escreva testes muito rápidos

Motivações para o uso do TDD
• Design pouco testável
• Baixa cobertura de testes unitários
• Necessidade de levantar todo o ambiente para
poder testar
• Necessidade de manter compatibilidade retroativa
• Insegurança ao modiﬁcar a base de código

Benefícios em usar TDD
• Suíte de regressão
• Testes são feitos na IDE
• Bugs comprovados por testes unitários
• Código mais testável
• Facilita o refactoring
• Evita o “overdesign”
• Colabora com a documentação

Ponderações sobre o uso do TDD
• Demora mais?
• No início é necessário escrever muitos testes
• Suite de regressão
• Certeza de que a implementação está rodando
• Maioria dos bugs encontrados em tempo de
desenvolvimento
• Bugs corrigidos mais rápidos

TDD é código que funciona
• Previsível
• Aprendizagem
• Conﬁança
• Documentação
• Proteção
• Teste suite automatizado

Quando devo parar?
• O sistema funciona
• O código comunica o que está fazendo
• Não existe código duplicado
• O sistema deveria ter a menor quantidade possível
de classes e métodos

TDD é sobre design, não sobre testes
• Use TDD para produzir algo simples que funcione
(KISS)
• Guie o design do software através dos testes
• Foque sobre escrever soluções simples para os
requisitos
• Escreva somente código para o teste passar
• Remova código duplicado (DRY)

TDD vs UML
• Análise prévia do problema
• Reutilização de código
• Linguagem uniﬁcada para especiﬁcação de
sistemas
• Aumento na qualidade
• Ferramenta de aprendizado
• Facilidade de manutenção

Tópico para discussão
• Deveríamos testar métodos privados?
• Sempre devemos usar TDD?

Perguntas?

Obrigado!

Test-Driven Development (Parte II)

Agenda
• Revisão
• JUnit
• Mock
• Padrões de TDD
• Exercícios

Cenas dos capítulos anteriores...

JUnit
• Annotations
• @Test
• @Before e @After
• @BeforeClass e @AfterClass
• @Test(expected = ArithmeticException.class)
• @Ignore
• @Test(timeout = 1000)

JUnit
Assertions do JUnit

Exemplo de mock (Simples)

Exemplo de mock (Um pouco mais
complexo)

Padrões de TDD
• O que queremos testar?
• Quando testamos?
• Como escolhemos que lógica testar?
• Como escolhemos quais dados testar?

Padrões de TDD
• Teste (substantivo)
• Teste isolado
• Lista de testes
• Teste primeiro
• Deﬁna uma asserção primeiro
• Dados de teste
• Dados evidentes

Exercícios de TDD
• Valida RG
• Valida Chassi
• Valida CPF

Test-Driven Development (Parte III)

Agenda
• Exercício

Dinheiro Multi-Moeda
Instrumento Ações Preço Total
Apple 1000 25 USD 25000 USD
Google 400 150 CHF 60000 CHF
TotalTotalTotal 65000 USD
De Para Taxa
CHF USD 1,5

Refactoring (Parte I)

Agenda
• Conceitos básicos
• Exemplo

O que é refactoring?

Refactoring (Parte II)

Agenda
• Conceitos básicos
• Motivos para refatorar
• Princípios de design de software
• “Mau cheiro”
• Ciclo do refactoring
• Técnicas de refactoring
• Exercício

• Refactoring(substantivo) - Mudança feita na
estrutura interna do software para fazê-lo fácil de
ler e barato de mudar sem alterar seu
comportamento
• Refactor(verbo) - Reestruturar o software através
de uma série de refactorings sem alterar seu
compotamento

O propósito do refactoring é fazer o
software fácil de entender e modiﬁcar

Por que você deveria refatorar?

Alguns porquês...
• Melhorar o design do software
• Fazer o software mais fácil de entender
• Encontrar bugs
• Escrever código mais rapidamente

Princípios de design de software
• Princípio da responsabilidade única
• Princípio aberto fechado
• Princípio da substituição de Liskov
• Princípio da injeção de dependência
• Princípio de segregação de interface

“Mau cheiro” no código(Não é isso)

“Mau cheiro” no código

O ciclo do refactoring
• O escolha o “mau cheiro”
• Selecione uma refatoração
• Aplique a refatoração
• Execute todos os testes

Técnicas de Refactoring

TDD e Refactoring

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (18)

Ähnlich wie TDD e Refactoring

Ähnlich wie TDD e Refactoring (20)

Mehr von André Pitombeira

Mehr von André Pitombeira (6)

TDD e Refactoring