Palestrante Thiago Faria de Andrade <ul><ul><li>Programador há mais de 15 anos </li></ul></ul><ul><ul><li>9 anos de experi...
Agenda <ul><ul><li>O que é TDD? </li></ul></ul><ul><ul><li>Quem inventou? </li></ul></ul><ul><ul><li>Espiral da morte </li...
O que é TDD? <ul><ul><li>Técnica de desenvolvimento de software </li></ul></ul><ul><ul><li>Testes unitários automatizados ...
O que é TDD? <ul><ul><li>Já sei, é um método para testar software! </li></ul></ul>
O que é TDD? <ul><ul><li>Não é um método para testar software </li></ul></ul><ul><ul><li>É um método para  construir  soft...
O que é TDD? <ul><ul><li>Através do processo “vermelho-verde-refatorar” </li></ul></ul><ul><ul><li>Com “código limpo que f...
Quem inventou? <ul><ul><li>Não sei… </li></ul></ul><ul><ul><li>Mas um criador de cabras que redescobriu TDD. </li></ul></u...
Espiral da morte “sem tempo para testar”
Benefícios <ul><ul><li>Testes unitários sempre atualizados </li></ul></ul><ul><ul><li>Design guiado pelos testes </li></ul...
Padrões do TDD <ul><ul><li>Crie uma lista de testes </li></ul></ul><ul><ul><li>Faça um brainstorm </li></ul></ul><ul><ul><...
Padrões do TDD <ul><ul><li>Crie testes isolados uns dos outros </li></ul></ul><ul><ul><li>Um teste não pode depender de ou...
Padrões do TDD <ul><ul><li>Teste primeiro </li></ul></ul><ul><ul><li>Escreva o teste antes do código que é para ser testad...
Padrões do TDD <ul><ul><li>Assertiva primeiro </li></ul></ul><ul><ul><li>Pense primeiro no sucesso do teste </li></ul></ul...
Padrões do TDD <ul><ul><li>Como assim? </li></ul></ul>
Padrões do TDD <ul><ul><li>Como assim? </li></ul></ul>
Padrões do TDD <ul><ul><li>Dados para teste </li></ul></ul><ul><ul><li>Não use números mágicos </li></ul></ul><ul><ul><li>...
Padrões do TDD <ul><ul><li>Use dados evidentes </li></ul></ul><ul><ul><li>Testes são para pessoas, não para computadores <...
Padrões do TDD <ul><ul><li>Use dados evidentes </li></ul></ul>
Padrões do TDD <ul><ul><li>Ao invés de… </li></ul></ul>
Red Bar Patterns <ul><ul><li>Quando e onde escrever os testes? </li></ul></ul><ul><ul><li>Quando parar? </li></ul></ul>
Red Bar Patterns <ul><ul><li>Um passo de cada vez </li></ul></ul><ul><ul><li>Qual o próximo teste? </li></ul></ul><ul><ul>...
Red Bar Patterns <ul><ul><li>Primeiro teste </li></ul></ul><ul><ul><li>Não comece pelo mais completo </li></ul></ul><ul><u...
Red Bar Patterns <ul><ul><li>Explicação usando testes </li></ul></ul><ul><ul><li>Não dá para forçar ninguém a mudar a form...
Red Bar Patterns <ul><ul><li>Testes de estudo </li></ul></ul><ul><ul><li>Podemos escrever testes para componentes de terce...
Red Bar Patterns <ul><ul><li>Novo teste </li></ul></ul><ul><ul><li>O que fazer quando surgir uma discussão? </li></ul></ul...
Red Bar Patterns <ul><ul><li>Teste de regressão </li></ul></ul><ul><ul><li>Se um defeito for encontrado, escreva um pequen...
Red Bar Patterns <ul><ul><li>Pausa </li></ul></ul><ul><ul><li>Quando estiver cansado, dê uma pausa </li></ul></ul><ul><ul>...
Red Bar Patterns <ul><ul><li>Comece de novo </li></ul></ul><ul><ul><li>Se estiver perdido, jogue tudo fora e comece de nov...
Testing Patterns <ul><ul><li>Técnicas mais detalhadas de como escrever testes </li></ul></ul><ul><ul><li>Hum… legal! </li>...
Testing Patterns <ul><ul><li>Testes menores </li></ul></ul><ul><ul><li>Se o teste ficou grande demais, deixe-o e escreva u...
Testing Patterns <ul><ul><li>Objetos dublês (mock) </li></ul></ul><ul><ul><li>Como testar objetos que dependem de recursos...
Testing Patterns <ul><ul><li>Teste de falhas </li></ul></ul><ul><ul><li>Como testar falhas difíceis de reproduzir? </li></...
Testing Patterns <ul><ul><li>Teste quebrado </li></ul></ul><ul><ul><li>Se está desenvolvendo um projeto sozinho, deixe sem...
Testing Patterns <ul><ul><li>Check-in limpo </li></ul></ul><ul><ul><li>Se trabalha em equipe, só faça  commit  quando os t...
Green Bar Patterns <ul><ul><li>Padrões para fazer o teste passar </li></ul></ul><ul><ul><li>Como fazer um teste vermelho f...
Green Bar Patterns <ul><ul><li>Falsifique até construir realmente </li></ul></ul><ul><ul><li>Implemente um código falso qu...
Green Bar Patterns <ul><ul><li>Triangulação </li></ul></ul><ul><ul><li>Abstraia métodos quando tiver dois ou mais testes <...
Green Bar Patterns <ul><ul><li>Implementação óbvia </li></ul></ul><ul><ul><li>Como implementar operações simples? </li></u...
Green Bar Patterns <ul><ul><li>Coleções </li></ul></ul><ul><ul><li>Para implementar operações sobre coleções, implemente p...
Padrões xUnit <ul><ul><li>xUnit é o nome genérico para ferramentas de testes unitários </li></ul></ul><ul><ul><li>Vamos co...
Padrões xUnit <ul><ul><li>Asserções </li></ul></ul><ul><ul><li>Escreva expressões booleanas que automatizam o julgamento s...
Padrões xUnit <ul><ul><li>Construção </li></ul></ul><ul><ul><li>Como criar objetos comuns a vários testes? </li></ul></ul>...
Padrões xUnit <ul><ul><li>Liberação de recursos </li></ul></ul><ul><ul><li>Como liberar recursos externos após um teste? <...
Padrões xUnit <ul><ul><li>Método de teste </li></ul></ul><ul><ul><li>O nome do método pode começar com “test”, “deve”, “sh...
Padrões xUnit <ul><ul><li>Teste de exceção </li></ul></ul><ul><ul><li>Como testar exceções esperadas? </li></ul></ul><ul><...
Refatoração <ul><ul><li>Refatorar é melhorar o design do sistema sem alterar o comportamento </li></ul></ul><ul><ul><li>Co...
Refatoração <ul><ul><li>Reconcilie diferenças </li></ul></ul><ul><ul><li>Duas partes de códigos iguais podem ser eliminada...
Refatoração <ul><ul><li>Isole mudanças </li></ul></ul><ul><ul><li>Se precisar alterar uma parte de um método que possui vá...
Refatoração <ul><ul><li>Migre dados </li></ul></ul><ul><ul><li>Como mudar de uma estrutura de dados para outra? </li></ul>...
Refatoração <ul><ul><li>Extraia métodos </li></ul></ul><ul><ul><li>Como fazer um método longo e complicado fácil de ser li...
Refatoração <ul><ul><li>Elimine métodos </li></ul></ul><ul><ul><li>Como simplificar o código quando ele parece muito dispe...
Refatoração <ul><ul><li>Extraia interfaces </li></ul></ul><ul><ul><li>Como criar uma segunda implementação de operações em...
Refatoração <ul><ul><li>Mover métodos </li></ul></ul><ul><ul><li>Como mover métodos para outros lugares sem precisar modif...
Refatoração <ul><ul><li>Objetos como métodos </li></ul></ul><ul><ul><li>Como representar um método complicado que requer m...
Refatoração <ul><ul><li>Parâmetro de método para parâmetro de construtor </li></ul></ul><ul><ul><li>Se você passa os mesmo...
Dominando TDD <ul><ul><li>Perguntas que surgem ao iniciar com TDD. </li></ul></ul>
Dominando TDD <ul><ul><li>Qual o tamanho ideal dos passos? </li></ul></ul><ul><ul><li>Não existe uma regra </li></ul></ul>...
Dominando TDD <ul><ul><li>O que você precisa testar? </li></ul></ul><ul><ul><li>Você encontrará essa resposta praticando <...
Dominando TDD <ul><ul><li>Como você sabe se tem bons testes? </li></ul></ul><ul><ul><li>Alguns atributos que sugerem teste...
Dominando TDD <ul><ul><li>Quando você deve excluir um teste? </li></ul></ul><ul><ul><li>É bom ter muitos testes </li></ul>...
Dominando TDD <ul><ul><li>Como migrar um projeto existente para usar TDD? </li></ul></ul><ul><ul><li>O maior problema é qu...
Como aprender TDD <ul><ul><li>Leia livros </li></ul></ul>
Como aprender TDD <ul><ul><li>Assista vídeos na internet de pessoas usando TDD </li></ul></ul>
Como aprender TDD <ul><ul><li>Estude códigos de projetos que usam TDD </li></ul></ul>
Como aprender TDD <ul><ul><li>Pratique muito </li></ul></ul>
Perguntas? Thiago Faria de Andrade [email_address] Twitter: @ThiagoFAndrade Obrigado! www.algaworks.com Twitter: @algaworks
Próximos SlideShares
Carregando em…5
×

Test-Driven Development - Introdução ao método de construção de software guiado por testes

1.386 visualizações

Publicada em

Palestra sobre TDD ministrada por Thiago Faria de Andrade (AlgaWorks).

Publicada em: Tecnologia
0 comentários
3 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

Sem downloads
Visualizações
Visualizações totais
1.386
No SlideShare
0
A partir de incorporações
0
Número de incorporações
18
Ações
Compartilhamentos
0
Downloads
25
Comentários
0
Gostaram
3
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Test-Driven Development - Introdução ao método de construção de software guiado por testes

  1. 2. Palestrante Thiago Faria de Andrade <ul><ul><li>Programador há mais de 15 anos </li></ul></ul><ul><ul><li>9 anos de experiência com Java </li></ul></ul><ul><ul><li>Bacharel em Sistemas de Informação </li></ul></ul><ul><ul><li>Certificado como programador Java pela Sun </li></ul></ul><ul><ul><li>Consultor, arquiteto, desenvolvedor, escritor e instrutor Java </li></ul></ul><ul><ul><li>Diretor/Proprietário da AlgaWorks </li></ul></ul><ul><ul><li>Diretor de Tecnologia da Boobow </li></ul></ul>
  2. 3. Agenda <ul><ul><li>O que é TDD? </li></ul></ul><ul><ul><li>Quem inventou? </li></ul></ul><ul><ul><li>Espiral da morte </li></ul></ul><ul><ul><li>Benefícios </li></ul></ul><ul><ul><li>Padrões do TDD </li></ul></ul><ul><ul><li>Red Bar Patterns </li></ul></ul><ul><ul><li>Testing Patterns </li></ul></ul><ul><ul><li>Green Bar Patterns </li></ul></ul><ul><ul><li>Padrões xUnit </li></ul></ul><ul><ul><li>Refatoração </li></ul></ul><ul><ul><li>Dominando TDD </li></ul></ul><ul><ul><li>Como aprender TDD </li></ul></ul>
  3. 4. O que é TDD? <ul><ul><li>Técnica de desenvolvimento de software </li></ul></ul><ul><ul><li>Testes unitários automatizados </li></ul></ul><ul><ul><li>Test-first programming (da XP) </li></ul></ul><ul><ul><li>Processo formado por pequenas iterações </li></ul></ul>
  4. 5. O que é TDD? <ul><ul><li>Já sei, é um método para testar software! </li></ul></ul>
  5. 6. O que é TDD? <ul><ul><li>Não é um método para testar software </li></ul></ul><ul><ul><li>É um método para construir software </li></ul></ul>
  6. 7. O que é TDD? <ul><ul><li>Através do processo “vermelho-verde-refatorar” </li></ul></ul><ul><ul><li>Com “código limpo que funciona” (Ron Jefrries) </li></ul></ul>
  7. 8. Quem inventou? <ul><ul><li>Não sei… </li></ul></ul><ul><ul><li>Mas um criador de cabras que redescobriu TDD. </li></ul></ul><ul><ul><li>@kentbeck </li></ul></ul>
  8. 9. Espiral da morte “sem tempo para testar”
  9. 10. Benefícios <ul><ul><li>Testes unitários sempre atualizados </li></ul></ul><ul><ul><li>Design guiado pelos testes </li></ul></ul><ul><ul><li>Aumento de confiança </li></ul></ul><ul><ul><li>Qualidade de código </li></ul></ul><ul><ul><li>Baixo acoplamento </li></ul></ul><ul><ul><li>Alta coesão </li></ul></ul><ul><ul><li>Código limpo </li></ul></ul><ul><ul><li>Testes são especificações </li></ul></ul>
  10. 11. Padrões do TDD <ul><ul><li>Crie uma lista de testes </li></ul></ul><ul><ul><li>Faça um brainstorm </li></ul></ul><ul><ul><li>Identifique e anote todos os testes que você precisará escrever </li></ul></ul><ul><ul><li>Faça isso para uma mesma classe ou método a ser testado </li></ul></ul><ul><ul><li>Durante o desenvolvimento, você pode adicionar novos testes a essa lista </li></ul></ul>
  11. 12. Padrões do TDD <ul><ul><li>Crie testes isolados uns dos outros </li></ul></ul><ul><ul><li>Um teste não pode depender de outro </li></ul></ul><ul><ul><li>Deve ser possível executar um teste isoladamente </li></ul></ul>
  12. 13. Padrões do TDD <ul><ul><li>Teste primeiro </li></ul></ul><ul><ul><li>Escreva o teste antes do código que é para ser testado </li></ul></ul><ul><ul><li>É uma oportunidade para pensar no design das classes </li></ul></ul><ul><ul><li>Uma forma de controlar o escopo do que será implementado </li></ul></ul>
  13. 14. Padrões do TDD <ul><ul><li>Assertiva primeiro </li></ul></ul><ul><ul><li>Pense primeiro no sucesso do teste </li></ul></ul><ul><ul><li>Depois pense se vai precisar de um método, de uma classe, os nomes dos parâmetros, etc </li></ul></ul>
  14. 15. Padrões do TDD <ul><ul><li>Como assim? </li></ul></ul>
  15. 16. Padrões do TDD <ul><ul><li>Como assim? </li></ul></ul>
  16. 17. Padrões do TDD <ul><ul><li>Dados para teste </li></ul></ul><ul><ul><li>Não use números mágicos </li></ul></ul><ul><ul><li>Evite passar o mesmo valor para diferentes parâmetros </li></ul></ul><ul><ul><li>Use dados do mundo real </li></ul></ul>
  17. 18. Padrões do TDD <ul><ul><li>Use dados evidentes </li></ul></ul><ul><ul><li>Testes são para pessoas, não para computadores </li></ul></ul><ul><ul><li>Escreva na assertiva uma expressão não só que representa o valor final esperado, mas o que ele significa </li></ul></ul>
  18. 19. Padrões do TDD <ul><ul><li>Use dados evidentes </li></ul></ul>
  19. 20. Padrões do TDD <ul><ul><li>Ao invés de… </li></ul></ul>
  20. 21. Red Bar Patterns <ul><ul><li>Quando e onde escrever os testes? </li></ul></ul><ul><ul><li>Quando parar? </li></ul></ul>
  21. 22. Red Bar Patterns <ul><ul><li>Um passo de cada vez </li></ul></ul><ul><ul><li>Qual o próximo teste? </li></ul></ul><ul><ul><li>O que você está confiante e vai lhe ensinar algo </li></ul></ul><ul><ul><li>Para cada pessoa a resposta é diferente </li></ul></ul><ul><ul><li>Cada teste deve representar um passo em direção ao objetivo final </li></ul></ul>
  22. 23. Red Bar Patterns <ul><ul><li>Primeiro teste </li></ul></ul><ul><ul><li>Não comece pelo mais completo </li></ul></ul><ul><ul><li>Comece pelo menor </li></ul></ul><ul><ul><li>Comece pelo mais simples </li></ul></ul>
  23. 24. Red Bar Patterns <ul><ul><li>Explicação usando testes </li></ul></ul><ul><ul><li>Não dá para forçar ninguém a mudar a forma de trabalhar </li></ul></ul><ul><ul><li>Peça explicações em termos de testes </li></ul></ul><ul><ul><li>Explique em termos de testes </li></ul></ul>
  24. 25. Red Bar Patterns <ul><ul><li>Testes de estudo </li></ul></ul><ul><ul><li>Podemos escrever testes para componentes de terceiros? </li></ul></ul><ul><ul><li>Apenas para estudar ou documentar o uso </li></ul></ul><ul><ul><li>Não teste todos os recursos do componente terceiro </li></ul></ul>
  25. 26. Red Bar Patterns <ul><ul><li>Novo teste </li></ul></ul><ul><ul><li>O que fazer quando surgir uma discussão? </li></ul></ul><ul><ul><li>Adicione um novo item na lista de testes </li></ul></ul><ul><ul><li>Volte ao assunto principal </li></ul></ul>
  26. 27. Red Bar Patterns <ul><ul><li>Teste de regressão </li></ul></ul><ul><ul><li>Se um defeito for encontrado, escreva um pequeno teste que falha, execute e depois implemente a correção </li></ul></ul><ul><ul><li>Para escrever o teste, pense em como você teria feito se fosse no passado </li></ul></ul>
  27. 28. Red Bar Patterns <ul><ul><li>Pausa </li></ul></ul><ul><ul><li>Quando estiver cansado, dê uma pausa </li></ul></ul><ul><ul><li>Beba água, descanse, tenha outros compromissos diferentes e saia de férias </li></ul></ul>
  28. 29. Red Bar Patterns <ul><ul><li>Comece de novo </li></ul></ul><ul><ul><li>Se estiver perdido, jogue tudo fora e comece de novo </li></ul></ul>
  29. 30. Testing Patterns <ul><ul><li>Técnicas mais detalhadas de como escrever testes </li></ul></ul><ul><ul><li>Hum… legal! </li></ul></ul>
  30. 31. Testing Patterns <ul><ul><li>Testes menores </li></ul></ul><ul><ul><li>Se o teste ficou grande demais, deixe-o e escreva um pequeno que representa parte dele </li></ul></ul><ul><ul><li>O ciclo “verde-vermelho-refatorar” deve ser rápido </li></ul></ul>
  31. 32. Testing Patterns <ul><ul><li>Objetos dublês (mock) </li></ul></ul><ul><ul><li>Como testar objetos que dependem de recursos externos, caros e complicados? </li></ul></ul><ul><ul><li>Crie uma versão falsa deles que retornam constantes </li></ul></ul><ul><ul><li>Existem diversas ferramentas para ajudar a fazer isso (eu uso o Mockito) </li></ul></ul>
  32. 33. Testing Patterns <ul><ul><li>Teste de falhas </li></ul></ul><ul><ul><li>Como testar falhas difíceis de reproduzir? </li></ul></ul><ul><ul><li>Falsifique o objeto </li></ul></ul><ul><ul><li>Construa uma nova classe que lance uma exceção </li></ul></ul>
  33. 34. Testing Patterns <ul><ul><li>Teste quebrado </li></ul></ul><ul><ul><li>Se está desenvolvendo um projeto sozinho, deixe sempre um teste em vermelho </li></ul></ul><ul><ul><li>Isso facilita a continuação no próximo dia </li></ul></ul>
  34. 35. Testing Patterns <ul><ul><li>Check-in limpo </li></ul></ul><ul><ul><li>Se trabalha em equipe, só faça commit quando os testes estiverem verdes </li></ul></ul><ul><ul><li>Execute todos os testes antes de submeter o código </li></ul></ul>
  35. 36. Green Bar Patterns <ul><ul><li>Padrões para fazer o teste passar </li></ul></ul><ul><ul><li>Como fazer um teste vermelho ficar verde rapidamente? </li></ul></ul>
  36. 37. Green Bar Patterns <ul><ul><li>Falsifique até construir realmente </li></ul></ul><ul><ul><li>Implemente um código falso que retorna uma constante (só para fazer o teste passar) </li></ul></ul><ul><ul><li>Ter algo rodando é melhor que não ter </li></ul></ul><ul><ul><li>Isso gera um bom efeito psicológico </li></ul></ul>
  37. 38. Green Bar Patterns <ul><ul><li>Triangulação </li></ul></ul><ul><ul><li>Abstraia métodos quando tiver dois ou mais testes </li></ul></ul><ul><ul><li>Quando fazemos isso, somos forçados a implementar algo que realmente funciona (sem falsificação) </li></ul></ul>
  38. 39. Green Bar Patterns <ul><ul><li>Implementação óbvia </li></ul></ul><ul><ul><li>Como implementar operações simples? </li></ul></ul><ul><ul><li>Apenas codifique a solução diretamente </li></ul></ul><ul><ul><li>Se sabe o que precisa digitar, então faça </li></ul></ul><ul><ul><li>Prepare-se para voltar atrás e dar um passo menor se suas mão não conseguirem acompanhar seu cérebro </li></ul></ul>
  39. 40. Green Bar Patterns <ul><ul><li>Coleções </li></ul></ul><ul><ul><li>Para implementar operações sobre coleções, implemente primeiro sem coleções </li></ul></ul><ul><ul><li>Depois faça funcionar com coleções </li></ul></ul>
  40. 41. Padrões xUnit <ul><ul><li>xUnit é o nome genérico para ferramentas de testes unitários </li></ul></ul><ul><ul><li>Vamos conhecer alguns padrões para usar ferramentas da família xUnit </li></ul></ul>
  41. 42. Padrões xUnit <ul><ul><li>Asserções </li></ul></ul><ul><ul><li>Escreva expressões booleanas que automatizam o julgamento sobre quando o código funciona </li></ul></ul><ul><ul><li>Deve ser true se estiver ok e false quando houver algum problema </li></ul></ul><ul><ul><li>Seja específico na asserção </li></ul></ul><ul><ul><li>Inclua mensagens informativas na asserção </li></ul></ul>
  42. 43. Padrões xUnit <ul><ul><li>Construção </li></ul></ul><ul><ul><li>Como criar objetos comuns a vários testes? </li></ul></ul><ul><ul><li>Converta as variáveis locais dos testes em variáveis de instância </li></ul></ul><ul><ul><li>Implemente o método setUp() e inicialize as variáveis </li></ul></ul>
  43. 44. Padrões xUnit <ul><ul><li>Liberação de recursos </li></ul></ul><ul><ul><li>Como liberar recursos externos após um teste? </li></ul></ul><ul><ul><li>Implemente o método tearDown() e libere lá </li></ul></ul><ul><ul><li>O teste deve deixar o mundo exatamente como ele estava antes </li></ul></ul>
  44. 45. Padrões xUnit <ul><ul><li>Método de teste </li></ul></ul><ul><ul><li>O nome do método pode começar com “test”, “deve”, “should” ou nada disso </li></ul></ul><ul><ul><li>O nome do método deve comunicar o que está sendo testado </li></ul></ul><ul><ul><li>O código de teste deve ser curto e fácil de entender </li></ul></ul>
  45. 46. Padrões xUnit <ul><ul><li>Teste de exceção </li></ul></ul><ul><ul><li>Como testar exceções esperadas? </li></ul></ul><ul><ul><li>Capture e ignore a exceção e chame fail() se não houver exceção </li></ul></ul><ul><ul><li>Ou use algum recurso específico do framework </li></ul></ul>
  46. 47. Refatoração <ul><ul><li>Refatorar é melhorar o design do sistema sem alterar o comportamento </li></ul></ul><ul><ul><li>Como mudar o design do sistema radicalmente ou em pequenos passos? </li></ul></ul><ul><ul><li>Ao refatorar, os testes devem continuar verdes </li></ul></ul><ul><ul><li>Refatoramos para melhorar legibilidade, facilitar manutenção e melhorar performance </li></ul></ul>
  47. 48. Refatoração <ul><ul><li>Reconcilie diferenças </li></ul></ul><ul><ul><li>Duas partes de códigos iguais podem ser eliminadas </li></ul></ul><ul><ul><li>Dois loops similares, ao fazerem eles idênticos, podem ser fundidos em um só </li></ul></ul><ul><ul><li>Duas condições similares, ao fazerem idênticas, uma pode ser eliminada </li></ul></ul><ul><ul><li>Dois métodos ou classes similares, ao fazerem idênticos, um pode ser eliminado </li></ul></ul>
  48. 49. Refatoração <ul><ul><li>Isole mudanças </li></ul></ul><ul><ul><li>Se precisar alterar uma parte de um método que possui várias outras partes, isole primeiro o que precisa ser alterado com refatoração </li></ul></ul><ul><ul><li>Extrair métodos é a forma mais comum de fazer isso </li></ul></ul>
  49. 50. Refatoração <ul><ul><li>Migre dados </li></ul></ul><ul><ul><li>Como mudar de uma estrutura de dados para outra? </li></ul></ul><ul><ul><li>Crie uma nova variável e duplique os dados </li></ul></ul><ul><ul><li>Atribua a nova variável em todos os lugares </li></ul></ul><ul><ul><li>Use a nova variável em todos os lugares </li></ul></ul><ul><ul><li>Apague a variável antiga </li></ul></ul><ul><ul><li>Mantenha os testes sempre verdes entre os passos </li></ul></ul>
  50. 51. Refatoração <ul><ul><li>Extraia métodos </li></ul></ul><ul><ul><li>Como fazer um método longo e complicado fácil de ser lido? </li></ul></ul><ul><ul><li>Encontre uma parte do código que faça sentido ter seu próprio método (blocos em loops e caminhos de condições são candidatos) </li></ul></ul><ul><ul><li>Deixe o teste sempre verde durante as mudanças </li></ul></ul>
  51. 52. Refatoração <ul><ul><li>Elimine métodos </li></ul></ul><ul><ul><li>Como simplificar o código quando ele parece muito disperso e sem sentido? </li></ul></ul><ul><ul><li>Substitua a chamada do método pelo código do método </li></ul></ul><ul><ul><li>Entenda melhor o código e depois repense sobre a melhor forma de organizá-lo </li></ul></ul>
  52. 53. Refatoração <ul><ul><li>Extraia interfaces </li></ul></ul><ul><ul><li>Como criar uma segunda implementação de operações em Java? </li></ul></ul><ul><ul><li>Crie uma interface que especifica os métodos compartilhados com o nome da classe existente </li></ul></ul><ul><ul><li>Mude o nome da classe existente para algo que faça sentido </li></ul></ul><ul><ul><li>Adicione os métodos necessários na interface </li></ul></ul><ul><ul><li>Cuidado ao nomear as classes e a interface (dê nomes que realmente fazem sentido) </li></ul></ul>
  53. 54. Refatoração <ul><ul><li>Mover métodos </li></ul></ul><ul><ul><li>Como mover métodos para outros lugares sem precisar modificar quem os chamam? </li></ul></ul><ul><ul><li>Crie um novo método e mova o conteúdo do método antigo para dentro do novo método </li></ul></ul><ul><ul><li>Faça uma chamada ao novo método de dentro do método antigo </li></ul></ul>
  54. 55. Refatoração <ul><ul><li>Objetos como métodos </li></ul></ul><ul><ul><li>Como representar um método complicado que requer muitos parâmetros e variáveis locais? </li></ul></ul><ul><ul><li>Crie uma classe que recebe os mesmos parâmetros do método </li></ul></ul><ul><ul><li>Torne as variáveis locais do método em variáveis de instância da nova classe </li></ul></ul><ul><ul><li>Crie um método run() que execute o mesmo código do método antigo </li></ul></ul><ul><ul><li>No método antigo, instancie um objeto da nova classe e chame run() </li></ul></ul>
  55. 56. Refatoração <ul><ul><li>Parâmetro de método para parâmetro de construtor </li></ul></ul><ul><ul><li>Se você passa os mesmos parâmetros para vários métodos diferentes do mesmo objeto: </li></ul></ul><ul><ul><li>Crie um construtor que recebe os mesmos parâmetros </li></ul></ul><ul><ul><li>Adicione as variáveis de instância na classe com os mesmos nomes dos parâmetros e inicialize-as no construtor </li></ul></ul><ul><ul><li>Mude todas as referências às variáveis para incluir “this.variavel” </li></ul></ul>
  56. 57. Dominando TDD <ul><ul><li>Perguntas que surgem ao iniciar com TDD. </li></ul></ul>
  57. 58. Dominando TDD <ul><ul><li>Qual o tamanho ideal dos passos? </li></ul></ul><ul><ul><li>Não existe uma regra </li></ul></ul><ul><ul><li>Mas a tendência é que sejam passos pequenos </li></ul></ul><ul><ul><li>Quando sentir confortável, você poderá dar passos um pouco maiores </li></ul></ul><ul><ul><li>Ferramentas ajudam a pular etapas na fase de refatoração </li></ul></ul>
  58. 59. Dominando TDD <ul><ul><li>O que você precisa testar? </li></ul></ul><ul><ul><li>Você encontrará essa resposta praticando </li></ul></ul><ul><ul><li>Teste condições, loops, operações, polimorfismo </li></ul></ul><ul><ul><li>Teste apenas códigos que você escreve </li></ul></ul>
  59. 60. Dominando TDD <ul><ul><li>Como você sabe se tem bons testes? </li></ul></ul><ul><ul><li>Alguns atributos que sugerem testes ruins: </li></ul></ul><ul><ul><li>Código de configuração longo ou duplicado </li></ul></ul><ul><ul><li>Testes demorados para executar </li></ul></ul><ul><ul><li>Testes frágeis (que dependem do resultado de outros) </li></ul></ul>
  60. 61. Dominando TDD <ul><ul><li>Quando você deve excluir um teste? </li></ul></ul><ul><ul><li>É bom ter muitos testes </li></ul></ul><ul><ul><li>Mas se dois testes são redundantes </li></ul></ul><ul><ul><ul><li>Se excluir um diminuirá sua confiança, é melhor deixar assim </li></ul></ul></ul><ul><ul><ul><li>Se os dois testes seguem o mesmo fluxo mas comunicam cenários diferentes, deixe assim </li></ul></ul></ul><ul><ul><ul><li>Se ambos os testes comunicam a mesma coisa e a exclusão de um deles não diminui sua confiança, então exclua um </li></ul></ul></ul>
  61. 62. Dominando TDD <ul><ul><li>Como migrar um projeto existente para usar TDD? </li></ul></ul><ul><ul><li>O maior problema é que códigos escritos sem pensar nos testes normalmente são difíceis de testar </li></ul></ul><ul><ul><li>Mudanças no código são perigosas porque não existem testes para garantir o funcionamento </li></ul></ul><ul><ul><li>Se tiver partes do sistema que precisam ser simplificadas mas não precisam de mudança no momento, não faça nada </li></ul></ul><ul><ul><li>Quando precisar modificar um método, implemente os testes antes </li></ul></ul><ul><ul><li>Faça testes em nível de aplicação para garantir um certo nível de confiança </li></ul></ul>
  62. 63. Como aprender TDD <ul><ul><li>Leia livros </li></ul></ul>
  63. 64. Como aprender TDD <ul><ul><li>Assista vídeos na internet de pessoas usando TDD </li></ul></ul>
  64. 65. Como aprender TDD <ul><ul><li>Estude códigos de projetos que usam TDD </li></ul></ul>
  65. 66. Como aprender TDD <ul><ul><li>Pratique muito </li></ul></ul>
  66. 67. Perguntas? Thiago Faria de Andrade [email_address] Twitter: @ThiagoFAndrade Obrigado! www.algaworks.com Twitter: @algaworks

×