Your SlideShare is downloading. ×
Unit Tests (com e sem TDD), BDD, Métricas...
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

Unit Tests (com e sem TDD), BDD, Métricas...

852
views

Published on

Minha apresentação no ALM Summit 2012

Minha apresentação no ALM Summit 2012

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
852
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
10
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. O que temos para hoje: Por que estamos aqui!? Considerações sobre Unit Tests (com e sem TDD), BDD, Fakes, Code Clone (e algumas métricas) Elemar JR Microsoft C# MVP Gerente de P&D – Promob SolutionsTwitter [@elemarjr] | Facebook [facebook.com/elemarjr] | Blog [elemarjr.net] | e-mail [elemarjr@gmail.com]
  • 2. Apresentando Elemar JR 32 anos, pai, DEV e nerd Arquiteto, enxadrista, (ex) apaixonado por vinhos. Gosta de filosofia e teologia P&D na Promob onde trabalha há 14 anos Microsoft C# MVP janeiro 2012 Integrante do Void Podcast com Leandro Daniel [@leandronet] e Vinícius Quaiato [@vquaiato] Blogueiro e articulista elemarjr.net e www.infoq.com/br/author/Elemar-Jr. FOSS developer fluentil.org e github.com/elemarjrTwitter [@elemarjr] | Facebook [facebook.com/elemarjr] | Blog [elemarjr.net] | e-mail [elemarjr@gmail.com]
  • 3. Antes de começar: Precisamos entender os motivos Definindo os “porquês” Afinal, por que precisamos pensar sobre Unit Tests, BDD, Fakes, Code Clone e Whatever!?Twitter [@elemarjr] | Facebook [facebook.com/elemarjr] | Blog [elemarjr.net] | e-mail [elemarjr@gmail.com]
  • 4. Conceituando AgilidadeTwitter [@elemarjr] | Facebook [facebook.com/elemarjr] | Blog [elemarjr.net] | e-mail [elemarjr@gmail.com] agilemanifesto.org/iso/ptbr/
  • 5. Conceituando Boas práticasTwitter [@elemarjr] | Facebook [facebook.com/elemarjr] | Blog [elemarjr.net] | e-mail [elemarjr@gmail.com] bit.ly/boas-praticas
  • 6. Conceituando Boas práticasTwitter [@elemarjr] | Facebook [facebook.com/elemarjr] | Blog [elemarjr.net] | e-mail [elemarjr@gmail.com] bit.ly/boas-praticas
  • 7. Conceituando Boas práticasTwitter [@elemarjr] | Facebook [facebook.com/elemarjr] | Blog [elemarjr.net] | e-mail [elemarjr@gmail.com] bit.ly/boas-praticas
  • 8. Para pensar Desenvolver software é um processo de aprendizagemTwitter [@elemarjr] | Facebook [facebook.com/elemarjr] | Blog [elemarjr.net] | e-mail [elemarjr@gmail.com] bit.ly/dev-aprendizado
  • 9. Para pensar Em um projeto de software, SEMPRE, há surpresas In spite of the best efforts of our discipline, all but the most routine projects have elements of surprise. Interesting projects – those likely to provide the most benefit – usually have a lot of surprises. (Growing Object-Oriented Software, Guided by Tests)Twitter [@elemarjr] | Facebook [facebook.com/elemarjr] | Blog [elemarjr.net] | e-mail [elemarjr@gmail.com] bit.ly/dev-aprendizado
  • 10. Para pensar Em um projeto de software, SEMPRE, há mudanças They all know there will be changes, they just don’t know what changes. They need a process that will help them cope with uncertainty as their experience grows – to anticipate unanticipated chances. (Growing Object-Oriented Software, Guided by Tests)Twitter [@elemarjr] | Facebook [facebook.com/elemarjr] | Blog [elemarjr.net] | e-mail [elemarjr@gmail.com] bit.ly/dev-aprendizado
  • 11. Para pensar Feedback é importante Feedback de seu código Os melhores códigos são os mais fáceis de ler. Feedback de seus colegas Eles sabem se seu código funciona e se é fácil de ler. Feedback de seus clientes Internos e externos, sem esquecer dos especialistas de domínio. Feedback de seus testes Se não está fácil de testar, não está fácil de manter. Feedback de seu build Quanto esforço para colocar uma alteração em produção?Twitter [@elemarjr] | Facebook [facebook.com/elemarjr] | Blog [elemarjr.net] | e-mail [elemarjr@gmail.com] bit.ly/dev-feedback
  • 12. Para pensar Boas práticas são indicativos de senioridade A preguiça é a mãe do progresso. Se o homem não tivesse preguiça de caminhar, não teria inventado a roda. (Mário Quintana)Twitter [@elemarjr] | Facebook [facebook.com/elemarjr] | Blog [elemarjr.net] | e-mail [elemarjr@gmail.com] bit.ly/tdd-escolha-pessoal
  • 13. Para agir Feedback é importante Feedback de seu código Use métricas! (bit.ly/leandro-code-metrics) Feedback de seus colegas Use Daily-meetings e participe de Coding Dojos (elemarjr.net/tag/dojo/) Feedback de seus clientes “Automatize” suas especificações Feedback de seus testes Automatize seus testes “de unidade e de aceitação”. Feedback de seu build Automatize seu Build e seu Deploy. (http://bit.ly/dev-msbuild)Twitter [@elemarjr] | Facebook [facebook.com/elemarjr] | Blog [elemarjr.net] | e-mail [elemarjr@gmail.com] bit.ly/dev-feedback
  • 14. Automatizando o óbvio: Teste! Unit Tests and TDD in a NutshellTwitter [@elemarjr] | Facebook [facebook.com/elemarjr] | Blog [elemarjr.net] | e-mail [elemarjr@gmail.com] elemarjr.net/tag/testes/
  • 15. Importante Você deveria testar o seu software Independente de pressão de cronograma, você deveria testar o seu softwareTwitter [@elemarjr] | Facebook [facebook.com/elemarjr] | Blog [elemarjr.net] | e-mail [elemarjr@gmail.com] bit.ly/dev-falacia
  • 16. Para pensar O que você tem a perder? ... you have nothing to lose but your bugs. (Growing Object-Oriented Software, Guided by Tests)Twitter [@elemarjr] | Facebook [facebook.com/elemarjr] | Blog [elemarjr.net] | e-mail [elemarjr@gmail.com]
  • 17. Conceituando Unit Testing Unit testing is a method by which individual units of source code, sets of one or more computer program modules together with associated control data, usage procedures, and operating procedures, are tested to determine if they are fit for use. (Wikipedia) Intuitively, one can view a unit as the smallest testable part of an application. In procedural programming a unit could be an entire module but is more commonly an individual function or procedure. In object-oriented programming a unit is often an entire interface, such as a class, but could be an individual method. (Wikipedia)Twitter [@elemarjr] | Facebook [facebook.com/elemarjr] | Blog [elemarjr.net] | e-mail [elemarjr@gmail.com] en.wikipedia.org/wiki/Unit_testing
  • 18. Como saber O que testar? Right – No contexto certo, os resultados são os esperados B – “limites” nos parâmetros/entradas (CORRECT!?) I – “prova-real” (exemplo) C – cross-check (comparação com implementações que funcionam) E – situações de falha (error conditions) P – PerformanceTwitter [@elemarjr] | Facebook [facebook.com/elemarjr] | Blog [elemarjr.net] | e-mail [elemarjr@gmail.com] bit.ly/Iixhkv
  • 19. Como saber O que testar (parâmetros)? C – (Conformance) adequação a um formato; O – (Ordering) respeito a um determinado critério de ordenação; R – (Range) intervalo válido (tipo, idade mínima e máxima); R – (Reference) acesso do SUT a outros objetos E – (Existence) valor não-nulo, tão pouco não-vazio; C – (Cardinality) os dados fornecidos são suficientes; T – (Time) Tudo está ocorrendo na sequência certa? Em ordem e no tempo esperado?! (está sendo disparado um evento PropertyChanged quando uma propriedade é alterada?!)Twitter [@elemarjr] | Facebook [facebook.com/elemarjr] | Blog [elemarjr.net] | e-mail [elemarjr@gmail.com] bit.ly/Iixhkv
  • 20. Para pensar Anatomia de um testeTwitter [@elemarjr] | Facebook [facebook.com/elemarjr] | Blog [elemarjr.net] | e-mail [elemarjr@gmail.com] SEM LINK
  • 21. Automatização A forma mais fácil de obter feedback contínuoTwitter [@elemarjr] | Facebook [facebook.com/elemarjr] | Blog [elemarjr.net] | e-mail [elemarjr@gmail.com] SEM LINK
  • 22. Para pensar Indicadores de Qualidade Complexidade Ciclomática, Índice de Manutenabilidade, Acoplamento aferente (referenciado em), Acoplamento eferente (referência para), Code Coverage, Code ClonesTwitter [@elemarjr] | Facebook [facebook.com/elemarjr] | Blog [elemarjr.net] | e-mail [elemarjr@gmail.com]
  • 23. Consequência Seu teste passa a influenciar o seu Design - TDDTwitter [@elemarjr] | Facebook [facebook.com/elemarjr] | Blog [elemarjr.net] | e-mail [elemarjr@gmail.com]
  • 24. Documentação viva: Learning TestsTwitter [@elemarjr] | Facebook [facebook.com/elemarjr] | Blog [elemarjr.net] | e-mail [elemarjr@gmail.com] bit.ly/LearningTests
  • 25. Quando a unidade é pouco: Testes de Integração e de Aceitação BDD in a Nutshell Porque fazer certo a coisa não implica, necessariamente, em fazer a coisa certa.Twitter [@elemarjr] | Facebook [facebook.com/elemarjr] | Blog [elemarjr.net] | e-mail [elemarjr@gmail.com] elemarjr.net/tag/BDD/
  • 26. Quando a unidade é pouco: Testes de Integração e de AceitaçãoTwitter [@elemarjr] | Facebook [facebook.com/elemarjr] | Blog [elemarjr.net] | e-mail [elemarjr@gmail.com] elemarjr.net/tag/BDD/
  • 27. Quando a unidade é pouco: Testes de Integração e de AceitaçãoTwitter [@elemarjr] | Facebook [facebook.com/elemarjr] | Blog [elemarjr.net] | e-mail [elemarjr@gmail.com] elemarjr.net/tag/BDD/
  • 28. Antecipando a “dor”: Quanto mais cedo testarmos...Twitter [@elemarjr] | Facebook [facebook.com/elemarjr] | Blog [elemarjr.net] | e-mail [elemarjr@gmail.com] elemarjr.net/tag/BDD/
  • 29. Walking Skeleton Sempre entregando o valorTwitter [@elemarjr] | Facebook [facebook.com/elemarjr] | Blog [elemarjr.net] | e-mail [elemarjr@gmail.com] elemarjr.net/tag/BDD/
  • 30. Walking Skeleton Ganhamos uma fonte adicional de feedbackTwitter [@elemarjr] | Facebook [facebook.com/elemarjr] | Blog [elemarjr.net] | e-mail [elemarjr@gmail.com] elemarjr.net/tag/BDD/
  • 31. Gherkin Requisitos como cenários de usoTwitter [@elemarjr] | Facebook [facebook.com/elemarjr] | Blog [elemarjr.net] | e-mail [elemarjr@gmail.com] elemarjr.net/tag/BDD/
  • 32. Gherkin Requisitos como cenários de usoTwitter [@elemarjr] | Facebook [facebook.com/elemarjr] | Blog [elemarjr.net] | e-mail [elemarjr@gmail.com] elemarjr.net/tag/BDD/
  • 33. BÔNUS: Quando o design não ajuda Alternativas para cenários Brownfield Nem sempre podemos dar “testabilidade” – Possíveis dívidas técnicas em testesTwitter [@elemarjr] | Facebook [facebook.com/elemarjr] | Blog [elemarjr.net] | e-mail [elemarjr@gmail.com]
  • 34. Métodos privados Testando o que não deveria ser testadoTwitter [@elemarjr] | Facebook [facebook.com/elemarjr] | Blog [elemarjr.net] | e-mail [elemarjr@gmail.com] bit.ly/teste_metodos_privados
  • 35. Métodos Estáticos Usando Microsoft FakesTwitter [@elemarjr] | Facebook [facebook.com/elemarjr] | Blog [elemarjr.net] | e-mail [elemarjr@gmail.com]
  • 36. FIM: Já devo ter estourado o tempo Por hoje, era isso!Twitter [@elemarjr] | Facebook [facebook.com/elemarjr] | Blog [elemarjr.net] | e-mail [elemarjr@gmail.com]

×