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

Saturday, May 25, 13

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?

Saturday, May 25, 13

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

Saturday, May 25, 13

Programação

• Primeira parte

• Test-Driven Development (TDD)

• Segunda parte

• Refactoring

Saturday, May 25, 13

Test-Driven Development (Parte I)

Saturday, May 25, 13

Agenda

• Motivação

• Famílias e tipos de testes

• Teste unitário

• Test-Driven Development

• Exercício de fixação

Saturday, May 25, 13

O problema

Barato Rápido

Bom

Saturday, May 25, 13

No silver bullet!

Saturday, May 25, 13

Porém, com testes...

• Um pouco mais rápido

• Um pouco mais barato

• Um pouco melhor

Saturday, May 25, 13

Rápido

0

250

500

750

1000

Projeto Implementação QA Post-release

Tempo gasto para resolver bugs

Saturday, May 25, 13

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

Saturday, May 25, 13

Melhor

• Desenvolvimento tradicional

• Instintivo

• Difícil de mensurar

• TDD

• Indicativo

• Mensurável

• Testável

Saturday, May 25, 13

Então, a solução é testar

Saturday, May 25, 13

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

Saturday, May 25, 13

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

Saturday, May 25, 13

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

Saturday, May 25, 13

O que é um teste de software?

Saturday, May 25, 13

“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

Saturday, May 25, 13

O que é qualidade de software?

Saturday, May 25, 13

“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

Saturday, May 25, 13

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

Saturday, May 25, 13

Famílias de Teste

• XUnit (JUnit, PyUnit, JsUnit)

• “assert”

• TAP (libtap)

• “ok” ou “is”

Saturday, May 25, 13

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

Saturday, May 25, 13

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

Saturday, May 25, 13

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

Saturday, May 25, 13

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)); }

Saturday, May 25, 13

hands-on!

Saturday, May 25, 13

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

Saturday, May 25, 13

Ciclo do desenvolvimento com TDD

Saturday, May 25, 13

Regras fundamentais do TDD

• Escreva somente o código suficiente para o teste passar

• Escreva testes pequenos

• Escreva testes muito rápidos

Saturday, May 25, 13

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

Saturday, May 25, 13

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

Saturday, May 25, 13

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

Saturday, May 25, 13

TDD é código que funciona

• Previsível

• Aprendizagem

• Confiança

• Documentação

• Proteção

• Teste suite automatizado

Saturday, May 25, 13

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

Saturday, May 25, 13

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)

Saturday, May 25, 13

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

Saturday, May 25, 13

hands-on!

Saturday, May 25, 13

Tópico para discussão

• Deveríamos testar métodos privados?

• Sempre devemos usar TDD?

Saturday, May 25, 13

Perguntas?

Saturday, May 25, 13

Obrigado!

Saturday, May 25, 13

Test-Driven Development (Parte II)

Saturday, May 25, 13

Agenda

• Revisão

• JUnit

• Mock

• Padrões de TDD

• Exercícios

Saturday, May 25, 13

Cenas dos capítulos anteriores...

Saturday, May 25, 13

Cenas dos capítulos anteriores...

Saturday, May 25, 13

JUnit

Saturday, May 25, 13

JUnit

• Annotations

• @Test

• @Before e @After

• @BeforeClass e @AfterClass

• @Test(expected = ArithmeticException.class)

• @Ignore

• @Test(timeout = 1000)

Saturday, May 25, 13

JUnit

Assertions do JUnit

Saturday, May 25, 13

Mock

Saturday, May 25, 13

Exemplo de mock (Simples)

Saturday, May 25, 13

Exemplo de mock (Um pouco mais complexo)

Saturday, May 25, 13

Padrões de TDD

• O que queremos testar?

• Quando testamos?

• Como escolhemos que lógica testar?

• Como escolhemos quais dados testar?

Saturday, May 25, 13

Padrões de TDD

• Teste (substantivo)

• Teste isolado

• Lista de testes

• Teste primeiro

• Defina uma asserção primeiro

• Dados de teste

• Dados evidentes

Saturday, May 25, 13

Exercícios de TDD

• Valida RG

• Valida Chassi

• Valida CPF

Saturday, May 25, 13

Saturday, May 25, 13

Saturday, May 25, 13

Saturday, May 25, 13

Saturday, May 25, 13

Test-Driven Development (Parte III)

Saturday, May 25, 13

Agenda

• Exercício

Saturday, May 25, 13

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

Saturday, May 25, 13

Saturday, May 25, 13

Saturday, May 25, 13

Refactoring (Parte I)

Saturday, May 25, 13

Agenda

• Conceitos básicos

• Exemplo

Saturday, May 25, 13

O que é refactoring?

Saturday, May 25, 13

Saturday, May 25, 13

hands-on!

Saturday, May 25, 13

Saturday, May 25, 13

Saturday, May 25, 13

Refactoring (Parte II)

Saturday, May 25, 13

Agenda

• Conceitos básicos

• Motivos para refatorar

• Princípios de design de software

• “Mau cheiro”

• Ciclo do refactoring

• Técnicas de refactoring

• Exercício

Saturday, May 25, 13

• 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

Saturday, May 25, 13

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

Saturday, May 25, 13

Por que você deveria refatorar?

Saturday, May 25, 13

Alguns porquês...

• Melhorar o design do software

• Fazer o software mais fácil de entender

• Encontrar bugs

• Escrever código mais rapidamente

Saturday, May 25, 13

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

Saturday, May 25, 13

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

Saturday, May 25, 13

“Mau cheiro” no código

Saturday, May 25, 13

O ciclo do refactoring

• O escolha o “mau cheiro”

• Selecione uma refatoração

• Aplique a refatoração

• Execute todos os testes

Saturday, May 25, 13

Técnicas de Refactoring

Saturday, May 25, 13

hands-on!

Saturday, May 25, 13

Saturday, May 25, 13

Saturday, May 25, 13