TDD e Refactoring

  • 594 views
Uploaded on

 

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
594
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
7
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. TDD e RefactoringAndré Luís PitombeiraSaturday, May 25, 13
  • 2. Quem sou eu?• Bacharel em Sistemas de Informação (UFC/Quixadá)• Bacharel em Administração de Empresas (FCRS)• Desenvolvedor de Software do lsbdSaturday, May 25, 13
  • 3. 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
  • 4. Objetivos• Definir os principais conceitos relacionados aoTDD e Refactoring• Mostrar boas práticas de programação e design desistemas• Demonstrar o uso de algumas ferramentasSaturday, May 25, 13
  • 5. Programação• Primeira parte• Test-Driven Development (TDD)• Segunda parte• RefactoringSaturday, May 25, 13
  • 6. Test-Driven Development (Parte I)Saturday, May 25, 13
  • 7. Agenda• Motivação• Famílias e tipos de testes• Teste unitário• Test-Driven Development• Exercício de fixaçãoSaturday, May 25, 13
  • 8. O problemaBarato RápidoBomSaturday, May 25, 13
  • 9. No silver bullet!Saturday, May 25, 13
  • 10. Porém, com testes...• Um pouco mais rápido• Um pouco mais barato• Um pouco melhorSaturday, May 25, 13
  • 11. Rápido02505007501000Projeto Implementação QA Post-releaseTempo gasto para resolver bugsSaturday, May 25, 13
  • 12. Barato• Bugs são descobertos nas fases iniciais dodesenvolvimento• Custo para resolver bug = Número de bugs /Custo por bug resolvido• Custo dos testes = Número de features /Complexidade das featuresSaturday, May 25, 13
  • 13. Melhor• Desenvolvimento tradicional• Instintivo• Difícil de mensurar• TDD• Indicativo• Mensurável• TestávelSaturday, May 25, 13
  • 14. Então, a solução é testarSaturday, May 25, 13
  • 15. Mas por que os desenvolvedoresdeveriam 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 testaro códigoSaturday, May 25, 13
  • 16. Os desenvolvedores deveriamconsiderar isto...• Como os desenvolvedores vão saber que estãofazendo software de qualidade sem os testes?• Testes são uma ferramenta para ajudar osdesenvolvedores a contribuírem para qualidade• Testes ajudam a dar perquenos passos e receberfeedback constante• Testes ajudam a manter o foco sobremensuráveis resultados de desenvolvimentoSaturday, May 25, 13
  • 17. Panorama da indústria• Principais problemas relatados na adoção detestes pela indústria• Aumenta o tempo de desenvolvimento• Experiência ou habilidade insuficiente• Insuficiente design• Insuficiente aderência ao TDD• Falta de ferramentasSaturday, May 25, 13
  • 18. O que é um teste de software?Saturday, May 25, 13
  • 19. “O teste de software é ainvestigação do software a fimde fornecer informações sobresua qualidade em relação aocontexto em que ele deveoperar. Isto inclui o processo deutilizar o produto paraencontrar seus defeitos.”WikipediaSaturday, May 25, 13
  • 20. O que é qualidade de software?Saturday, May 25, 13
  • 21. “A qualidade de software é umaárea de conhecimento daengenharia de software queobjetiva garantir a qualidade dosoftware através da definição enormatização de processos dedesenvolvimento.” WikipediaSaturday, May 25, 13
  • 22. 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árioSaturday, May 25, 13
  • 23. Famílias de Teste• XUnit (JUnit, PyUnit, JsUnit)• “assert”• TAP (libtap)• “ok” ou “is”Saturday, May 25, 13
  • 24. Teste unitário“Teste unitário é o método pelo qual unidades decódigo são testadas para verificar se estas estão aptaspara o uso. Uma unidade é a menor parte testável deuma aplicação.” WikepediaSaturday, May 25, 13
  • 25. 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 softwareSaturday, May 25, 13
  • 26. Teste unitário é bom se...• É realmente automático• Testa tudo que é provável quebrar• Deve ser independente de ambiente e de outrostestes• Deve ser repetitivo e mostrar sempre o mesmoresultado toda vez que executar• O teste deve ser claroSaturday, May 25, 13
  • 27. Exemplo de teste unitáriopublic 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
  • 28. hands-on!Saturday, May 25, 13
  • 29. O que é TDD?• Uma técnica iterativa para desenvolver software• Escreva primeiro um teste que falha(ou até mesmonão compile), antes de escrever uma novafuncionalidade• O objetivo do TDD é especificação e não validação• Uma prática para evoluir o código eficientementeSaturday, May 25, 13
  • 30. Ciclo do desenvolvimento com TDDSaturday, May 25, 13
  • 31. Regras fundamentais do TDD• Escreva somente o código suficiente para o testepassar• Escreva testes pequenos• Escreva testes muito rápidosSaturday, May 25, 13
  • 32. Motivações para o uso do TDD• Design pouco testável• Baixa cobertura de testes unitários• Necessidade de levantar todo o ambiente parapoder testar• Necessidade de manter compatibilidade retroativa• Insegurança ao modificar a base de códigoSaturday, May 25, 13
  • 33. 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çãoSaturday, May 25, 13
  • 34. 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 dedesenvolvimento• Bugs corrigidos mais rápidosSaturday, May 25, 13
  • 35. TDD é código que funciona• Previsível• Aprendizagem• Confiança• Documentação• Proteção• Teste suite automatizadoSaturday, May 25, 13
  • 36. 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ívelde classes e métodosSaturday, May 25, 13
  • 37. 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 osrequisitos• Escreva somente código para o teste passar• Remova código duplicado (DRY)Saturday, May 25, 13
  • 38. TDD vs UML• Análise prévia do problema• Reutilização de código• Linguagem unificada para especificação desistemas• Aumento na qualidade• Ferramenta de aprendizado• Facilidade de manutençãoSaturday, May 25, 13
  • 39. hands-on!Saturday, May 25, 13
  • 40. Tópico para discussão• Deveríamos testar métodos privados?• Sempre devemos usar TDD?Saturday, May 25, 13
  • 41. Perguntas?Saturday, May 25, 13
  • 42. Obrigado!Saturday, May 25, 13
  • 43. Test-Driven Development (Parte II)Saturday, May 25, 13
  • 44. Agenda• Revisão• JUnit• Mock• Padrões de TDD• ExercíciosSaturday, May 25, 13
  • 45. Cenas dos capítulos anteriores...Saturday, May 25, 13
  • 46. Cenas dos capítulos anteriores...Saturday, May 25, 13
  • 47. JUnitSaturday, May 25, 13
  • 48. JUnit• Annotations• @Test• @Before e @After• @BeforeClass e @AfterClass• @Test(expected = ArithmeticException.class)• @Ignore• @Test(timeout = 1000)Saturday, May 25, 13
  • 49. JUnitAssertions do JUnitSaturday, May 25, 13
  • 50. MockSaturday, May 25, 13
  • 51. Exemplo de mock (Simples)Saturday, May 25, 13
  • 52. Exemplo de mock (Um pouco maiscomplexo)Saturday, May 25, 13
  • 53. 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
  • 54. Padrões de TDD• Teste (substantivo)• Teste isolado• Lista de testes• Teste primeiro• Defina uma asserção primeiro• Dados de teste• Dados evidentesSaturday, May 25, 13
  • 55. Exercícios de TDD• Valida RG• Valida Chassi• Valida CPFSaturday, May 25, 13
  • 56. Saturday, May 25, 13
  • 57. Saturday, May 25, 13
  • 58. Saturday, May 25, 13
  • 59. Saturday, May 25, 13
  • 60. Test-Driven Development (Parte III)Saturday, May 25, 13
  • 61. Agenda• ExercícioSaturday, May 25, 13
  • 62. Dinheiro Multi-MoedaInstrumento Ações Preço TotalApple 1000 25 USD 25000 USDGoogle 400 150 CHF 60000 CHFTotalTotalTotal 65000 USDDe Para TaxaCHF USD 1,5Saturday, May 25, 13
  • 63. Saturday, May 25, 13
  • 64. Saturday, May 25, 13
  • 65. Refactoring (Parte I)Saturday, May 25, 13
  • 66. Agenda• Conceitos básicos• ExemploSaturday, May 25, 13
  • 67. O que é refactoring?Saturday, May 25, 13
  • 68. Saturday, May 25, 13
  • 69. hands-on!Saturday, May 25, 13
  • 70. Saturday, May 25, 13
  • 71. Saturday, May 25, 13
  • 72. Refactoring (Parte II)Saturday, May 25, 13
  • 73. Agenda• Conceitos básicos• Motivos para refatorar• Princípios de design de software• “Mau cheiro”• Ciclo do refactoring• Técnicas de refactoring• ExercícioSaturday, May 25, 13
  • 74. • Refactoring(substantivo) - Mudança feita naestrutura interna do software para fazê-lo fácil deler e barato de mudar sem alterar seucomportamento• Refactor(verbo) - Reestruturar o software atravésde uma série de refactorings sem alterar seucompotamentoSaturday, May 25, 13
  • 75. O propósito do refactoring é fazer osoftware fácil de entender e modificarSaturday, May 25, 13
  • 76. Por que você deveria refatorar?Saturday, May 25, 13
  • 77. Alguns porquês...• Melhorar o design do software• Fazer o software mais fácil de entender• Encontrar bugs• Escrever código mais rapidamenteSaturday, May 25, 13
  • 78. 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 interfaceSaturday, May 25, 13
  • 79. “Mau cheiro” no código(Não é isso)Saturday, May 25, 13
  • 80. “Mau cheiro” no códigoSaturday, May 25, 13
  • 81. O ciclo do refactoring• O escolha o “mau cheiro”• Selecione uma refatoração• Aplique a refatoração• Execute todos os testesSaturday, May 25, 13
  • 82. Técnicas de RefactoringSaturday, May 25, 13
  • 83. hands-on!Saturday, May 25, 13
  • 84. Saturday, May 25, 13
  • 85. Saturday, May 25, 13