Your SlideShare is downloading. ×

TDD

240

Published on

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

  • Be the first to like this

No Downloads
Views
Total Views
240
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
8
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.  Agilidade e XP TDD TDD em .Net TDD na prática Referências
  • 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.  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.  Custo Tempo Qualidade Escopo*
  • 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.  Comunicação Simplicidade Feedback Respeito Coragem
  • 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.  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.  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.  Jogos de planejamento (planning poker) Semanas de 40 horas Ritmo sustentável Pequenos releases
  • 11.  Jogos de planejamento (planning poker) Código coletivo Programação em pares Refatorar sempre, sem misericórdia Integração contínua TDD
  • 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.  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.  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.  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.  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.  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.  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.  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.  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.  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.  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.  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.  TDD veio do Java mas ... Apoio pela IDE Apoio dos frameworks Inúmeros frameworks open-source também
  • 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.  Robert C. Martin (Uncle Bob) 2002
  • 27.  Kent Beck 2002
  • 28.  Robert C. Martin (Uncle Bob) 2008
  • 29.  Robert C. Martin (Uncle Bob) 2011
  • 30.  Kent Beck 2004
  • 31.  Eric Evans 2003
  • 32.  Jimmy Nilsson 2006
  • 33.  Martin Fowler 2009
  • 34.  Michael Feathers 2004
  • 35.  James Bender Jeff McWherter 2011

×