TDD

356 visualizações

Publicada em

0 comentários
0 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

  • Seja a primeira pessoa a gostar disto

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

Nenhuma nota no slide

TDD

  1. 1.  Agilidade e XP TDD TDD em .Net TDD na prática Referências
  2. 2.  Indivíduos e interação mais que processos e ferramentas Software funcionando mais que documentação abrangente Colaboração com o cliente mais que negociação de contratos Responder a mudanças mais que seguir um plano
  3. 3.  Kent Beck (XP, TDD) Mike Beedle Arie van Bennekum Alistair Cockburn Ward Cunningham Martin Fowler (Patterns, Refactoring) James Grenning Jim Highsmith Andrew Hunt Ron Jeffries Jon Kern Brian Marick Robert Martin (Clean Code, Agile) Steve Mellor Ken Schwaber (Scrum) Jeff Sutherland Dave Thomas
  4. 4.  Custo Tempo Qualidade Escopo*
  5. 5.  Simples, leve, rápido e divertido São as práticas que mais agradam os programadores e que causaram maior “barulho” nas empresas e na comunidade O primeiro livro de XP é o livro do Kent Beck
  6. 6.  Comunicação Simplicidade Feedback Respeito Coragem
  7. 7.  Espaço aberto (todos juntos com o cliente, sem baias, war rooms, flipcharts, lousas e etc) Programação em pares (nivelamento de conhecimento técnico e do projeto) Movimente as pessoas Cliente sempre próximo Código coletivo Metáfora do sistema TDD Padrões de código
  8. 8.  TDD (desenvolvimento guiado a testes) Modelagem simples (KISS - Keep it simple, stupid!) Ser simplista não é não pensar no futuro mas não faça aquilo que não é necessário Refatorar sempre, sem misericórdia Pequenos releases Metáfora do sistema Padrões de código
  9. 9.  Integração continua (controle de versão, servidor de build, testes, inspeção de código e feedback) Cliente sempre próximo Pequenos releases Programação em pares Código coletivo
  10. 10.  Jogos de planejamento (planning poker) Semanas de 40 horas Ritmo sustentável Pequenos releases
  11. 11.  Jogos de planejamento (planning poker) Código coletivo Programação em pares Refatorar sempre, sem misericórdia Integração contínua TDD
  12. 12.  Desenvolvimento guiado por testes O primeiro livro sobre o assunto também foi escrito pelo Kent Beck A prática mais viciante e uma das mais importantes do XP Fácil de explicar mas difícil de aprender (dói) e leva tempo, mas de retorno garantido
  13. 13.  Código mais claro Testes são documentações executáveis Testes garantem funcionalidades do domínio do problema Se algum teste parou de rodar, sabemos que algo deu errado Independência de uma camada gráfica para testar as camadas mais baixas(negócios, db, etc) Economia de tempo e dinheiro em manutenção
  14. 14.  Você deve criar uma grande quantidade de testes Nenhum código vai para produção sem ter um teste correspondente O teste SEMPRE é escrito antes Rode seus testes com frequencia O teste te diz que código de produção você deve escrever Primeiro eu codifico o teste, depois codifico o código de produção
  15. 15.  Não escreva código de produção até que você tenha escrito um teste unitário falho Não escreva mais do que um teste que já seja suficiente para falhar, não compilar é uma falha Não escreva no código de produção mais do que o suficiente para passar no seu teste falho
  16. 16.  Testar é fácil, se está difícil escrever um teste o código está mal feito TDD nos leva a usar boas práticas de modelagem e arquitetura TDD nos leva a um baixo acoplamento TDD nos leva a desenvolver para interfaces Refatore sem medo, afinal você está coberto pelos testes
  17. 17.  Sempre que encontrar um bug escreva um teste que o exponha Os testes devem evoluir, assim como o código evolui Testes que não são atualizados são apenas código legado Aprender a escrever testes é também um processo gradativo Crie testes as Exceptions
  18. 18.  Reescrever o código de forma que fique mais fácil o seu entendimento e por consequência a sua manutenção Ninguém faz nada perfeito da primeira vez Na verdade não existe código perfeito, ele sempre tem alguma coisa que pode melhorar Será que eu não introduzi bugs quando refatorei?
  19. 19.  Tanto o código de teste quanto o código de produção devem ser constantemente refatorados Durante o processo do TDD o código de produção é revisto várias vezes Criar testes me garante que posso refatorar a vontade, pois os testes vão me avisar caso eu insira algum bug
  20. 20.  Classes com nomes que sejam substantivos Métodos com nomes que sejam verbos Propriedades com nomes que sejam substantivos Variáveis com nomes que sejam substantivos Nomes que tenham significado de negócio Convenções de nomes Evite comentários no código, se você precisa comentar é porque seu código não está claro então reescreva
  21. 21.  Apenas um Assert por teste Um conceito por teste F.I.R.S.T. ◦ Fast – rápidos de rodar ◦ Independent – independentes entre si ◦ Repeatable – fáceis de executar a qualquer momento ◦ Self-Validating – fácil de descobrir se deu certo ou não ◦ Timely – teste deve ser feito pouco antes do código de produção
  22. 22.  São objetos fake que permitem que o teste seja isolado em apenas uma classe Serve para remover dependências que o teste pode ter como, banco de dados, web services, outras classes, entre outros
  23. 23.  Une classes e componentes em tempo de execução Permite que quando estivermos rodando os testes apontemos para classes stubs e quando o código for executado em produção volte para as classes originais Não é indispensável, mas é útil
  24. 24.  TDD veio do Java mas ... Apoio pela IDE Apoio dos frameworks Inúmeros frameworks open-source também
  25. 25.  Criação de testes unitários Criação de stubs Criação de classes e métodos automatizadamente Ambiente para execução dos testes unitários (Test Explorer) Ferramenta de análise de cobertura de código (Code Coverage) Ferramenta de análise da complexidade do código (Code Metrics) Ferramenta para teste de desempenho e carga (Performance Wizard)
  26. 26.  Robert C. Martin (Uncle Bob) 2002
  27. 27.  Kent Beck 2002
  28. 28.  Robert C. Martin (Uncle Bob) 2008
  29. 29.  Robert C. Martin (Uncle Bob) 2011
  30. 30.  Kent Beck 2004
  31. 31.  Eric Evans 2003
  32. 32.  Jimmy Nilsson 2006
  33. 33.  Martin Fowler 2009
  34. 34.  Michael Feathers 2004
  35. 35.  James Bender Jeff McWherter 2011

×