TDD e Refactoring

TDD e RefactoringAndré 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

• Definir 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 fixaçã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 fim 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 definiçã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 configuraçã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 verificar 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 é especificação e não validação

• Uma prática para evoluir o código eficientemente


Ciclo do desenvolvimento com TDD


Regras fundamentais do TDD

• Escreva somente o código suficiente 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 modificar 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

• Confianç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 unificada para especificação de sistemas

• Aumento na qualidade

• Ferramenta de aprendizado

• Facilidade de manutenção


hands-on!


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...


Cenas dos capítulos anteriores...


JUnit


JUnit

• Annotations

• @Test

• @Before e @After

• @BeforeClass e @AfterClass

• @Test(expected = ArithmeticException.class)

• @Ignore

• @Test(timeout = 1000)


JUnit

Assertions do JUnit


http://junit.sourceforge.net/javadoc/org/junit/Assert.html

http://junit.sourceforge.net/javadoc/org/junit/Assert.html

Mock


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

• Defina 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 TaxaCHF USD 1,5




Refactoring (Parte I)


Agenda

• Conceitos básicos

• Exemplo


O que é refactoring?



hands-on!




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 modificar


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


hands-on!




Documents

TDD e Refactoring