   Agilidade e XP   TDD   TDD em .Net   TDD na prática   Referências
   Indivíduos e interação mais que processos e    ferramentas   Software funcionando mais que    documentação abrangente...
   Kent Beck (XP, TDD)   Mike Beedle   Arie van Bennekum   Alistair Cockburn   Ward Cunningham   Martin Fowler (Patt...
   Custo   Tempo   Qualidade   Escopo*
   Simples, leve, rápido e divertido   São as práticas que mais agradam os    programadores e que causaram maior    “bar...
   Comunicação   Simplicidade   Feedback   Respeito   Coragem
   Espaço aberto (todos juntos com o cliente, sem    baias, war rooms, flipcharts, lousas e etc)   Programação em pares ...
   TDD (desenvolvimento guiado a testes)   Modelagem simples (KISS - Keep it simple,    stupid!)   Ser simplista não é ...
   Integração continua (controle de versão,    servidor de build, testes, inspeção de código    e feedback)   Cliente se...
   Jogos de planejamento (planning poker)   Semanas de 40 horas   Ritmo sustentável   Pequenos releases
   Jogos de planejamento (planning poker)   Código coletivo   Programação em pares   Refatorar sempre, sem misericórdi...
   Desenvolvimento guiado por testes   O primeiro livro sobre o assunto também foi    escrito pelo Kent Beck   A prátic...
   Código mais claro   Testes são documentações executáveis   Testes garantem funcionalidades do domínio    do problema...
   Você deve criar uma grande quantidade de    testes   Nenhum código vai para produção sem ter    um teste corresponden...
   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 tes...
   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  ...
   Sempre que encontrar um bug escreva um    teste que o exponha   Os testes devem evoluir, assim como o    código evolu...
   Reescrever o código de forma que fique mais    fácil o seu entendimento e por consequência    a sua manutenção   Ning...
   Tanto o código de teste quanto o código de    produção devem ser constantemente    refatorados   Durante o processo d...
   Classes com nomes que sejam substantivos   Métodos com nomes que sejam verbos   Propriedades com nomes que sejam    ...
   Apenas um Assert por teste   Um conceito por teste   F.I.R.S.T.    ◦ Fast – rápidos de rodar    ◦ Independent – inde...
   São objetos fake que permitem que o teste    seja isolado em apenas uma classe   Serve para remover dependências que ...
   Une classes e componentes em tempo de    execução   Permite que quando estivermos rodando os    testes apontemos para...
   TDD veio do Java mas ...   Apoio pela IDE   Apoio dos frameworks   Inúmeros frameworks open-source também
   Criação de testes unitários   Criação de stubs   Criação de classes e métodos    automatizadamente   Ambiente para ...
   Robert C. Martin    (Uncle Bob)   2002
   Kent Beck   2002
   Robert C. Martin    (Uncle Bob)   2008
   Robert C. Martin    (Uncle Bob)   2011
   Kent Beck   2004
   Eric Evans   2003
   Jimmy Nilsson   2006
   Martin Fowler   2009
   Michael Feathers   2004
   James Bender   Jeff McWherter   2011
TDD
TDD
TDD
TDD
TDD
TDD
TDD
TDD
TDD
Upcoming SlideShare
Loading in …5
×

TDD

326 views
282 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
326
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
8
Comments
0
Likes
0
Embeds 0
No embeds

No notes for 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

×