Your SlideShare is downloading. ×
Introdução a TDD
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Introdução a TDD

626

Published on

Introduz TDD, situando em relação aos diversos tipos de testes existentes.

Introduz TDD, situando em relação aos diversos tipos de testes existentes.

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
626
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
18
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. Desenvolvimento Orientado por Testes Daniel Capó Sobral
  • 2. Ou não?
  • 3. Taxonomias• Funcional • Automático • Caixa Preta • Exploratório • Teste• Não • Manual • Caixa Branca • Pré-definido Primeiro Funcional • Caixa Cinza • Teste por Último Informação Momento deObjeto de teste Execução Planejamento sobre o sistema escrita• Qualitativo • Estático • Estado • Verificação • TDD• Quantitativo (tipos, • Interação • Validação • ATDD provas) • BDD • Dinâmico Execução do Comportamento Contratado vs Técnica deResultado código testado observado Desejado Escrita
  • 4. NíveisEscopo do Objeto TestadoUnit Testing Integration Testing System Testing System Integration Testing
  • 5. NíveisObjetivo do Teste Smoke Test Regressão Aceitação Alpha Beta
  • 6. Não funcional Performance Carga Usabilidade Internacionalização Segurança Destrutivo e Localização Compatibilidade Escalabilidade etc
  • 7. “In test-driven development a developer creates automated unittests” – wikipedia
  • 8. O que é TDD?TDD é sobre comoescrever código deaplicação. Teste Unitário Automatizado Teste Primeiro Técnica de Desenvolvimento de Software TDD não é sobre como escrever testes!
  • 9. Porque não fazer TDD? Curva de Aprendizado Íngreme: • Como escrever testes? • Como escrever código testável? • Como usar as ferramentas? • Como se faz TDD? Menor Produtividade • Mais linhas de código • Interrupções constantes Maior Custo de Manutenção • Mais código, mais manutenção • Mudanças de arquitetura quebram testes! • Mudanças de comportamento quebram testes!
  • 10. Porque fazer TDD? Menor Custo de Manutenção • Confiança para efetuar mudanças • Testes resguardam contra regressão Maior Produtividade • YAGNI! (You Ain’t Gonna Need It!) significa menos desperdício • Menos tempo corrigindo bugs: estava funcionando a cinco minutos atrás! Maior Qualidade • Mais testes leva a menos bugs • Testes unitários compreensivos resultam em baixo acoplamento
  • 11. O que dizem os estudos? • Inconclusivo • Boa correlação, mas... • Isolamento • TDD ou outras práticas ágeis? • TDD ou número de testes? Maior • Mais testes levam a menos bugs? Confirmado. Qualidade? • Curva de aprendizado íngreme dificulta grupos de controle • Inconclusivo • Conforme estudo, melhor, pior ou indiferente EaProdutividade?
  • 12. Famous last words.
  • 13. Dificuldades Que nome dar aos testes? Quanto se O que não testar de cada testar? vez? O que testar? Como Onde entender começar? porque o teste falhou? Como separar uma unidade de suas dependências? Fonte: Introducing BDD, Dan North
  • 14. O que é um bom teste unitário?Deve ser fácil de implementar.Deve ser automatizável e reproduzível de forma confiável.Qualquer um deve ser capaz de executá-lo, sem setups complicados.Deve ser executável com um simples click.Deve executar rapidamente.Uma vez escrito, deve ser preservado para uso futuro. Fonte: The Art of Unit Testing, Roy Osherove
  • 15. Teste (automatizado) é Código Arcabouço, Armação, Andaime Removido ao fim da Mas software sem manutenção Ajuda a construir construção é software morto! Atenção com Manutenção Qualidade Legibilidade Refatoração Code Rot Em outras palavras, deve receber as mesmas atenções que o código da aplicação!
  • 16. Removendo dependências: FakesStubs Mocks Teste de Teste de estado Interação Como? Asserções Injeção de Dependências Espelhamento
  • 17. Três leis de TDD Você não pode escrever código de aplicação exceto para fazer passar um teste unitário. Você não pode escrever código de teste mais do que o necessário para falhar; falhar compilação também conta.Você não pode escrever código de aplicação mais do que o suficiente para fazer um teste unitário passar. Segundo Robert Martin
  • 18. Três fases de TDD Vermelho • Escrever código de teste para evidenciar falha Azul Verde • Refactoring de • Escrever código código de aplicação (aplicação e para corrigir testes) falha
  • 19. Fluxo de TDD Não Executa teste Escrever teste Falhou? Sim Sim Sim Não Passou? Escrever aplicação Executa teste Executa teste Refatoração Sim Não Passou? (aplicação e testes)
  • 20. DemonstraçãoJogo de Boliche Regras:  10 jogadas (frames)  1 ou 2 arremessos por jogada (1ª à 9ª)  2 ou 3 arremessos na 10ª jogada  10 pinos  1 ponto por pino derrubado  Spare – 10 pinos derrubados em 2 arremessos  10 pontos + próximo arremesso  Strike – 10 pinos derrubados em 1 arremesso  10 pontos + 2 próximos arremessos
  • 21. Diagrama de Classe TODO
  • 22. Escrevendo o código com TDD TODO
  • 23. Discutir!
  • 24. Referências Clean Coders (Robert Martin) Making Software: What Really Works, and Why We Believe It (Andy Oram & Greg Wilson) The Art of Unit Testing: with Examples in .Net (Roy Osherove) Introducing BDD (Dan North) Wikipedia (duh!) Test Driven Development: By Example (Kent Beck)

×