Palestra Testes De Unidade Com JUnit

3,602 views

Published on

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

No Downloads
Views
Total views
3,602
On SlideShare
0
From Embeds
0
Number of Embeds
643
Actions
Shares
0
Downloads
232
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

Palestra Testes De Unidade Com JUnit

  1. 1. Testes de Unidade com JUnit Paulo César M. Jeveaux paulo.jeveaux@giran.com.br
  2. 2. Giran Soluções e Ensino • Consultoria e Treinamento especialidados • Java • Ruby on Rails • Desenvolvimento ágil • Gerenciamento de projetos com SCRUM • Profissionais altamente qualificados • Participação ativa na comunidade • http://www.giran.com.br
  3. 3. Jeveaux • CEO da Giran • Desenvolvedor Java há 8++ anos • Fundador do ESJUG e Agile-ES • Administrador do PortalJava.com • Palestrante e evangelista Java • Entusiasta Ruby, Rails, Python e Agile • Curioso e aprendendo Erlang
  4. 4. Sobre o que vamos falar hoje...
  5. 5. desenvolvimento de software
  6. 6. desenvolvimento de software processo tradicional
  7. 7. desenvolvimento de software processo tradicional um pouquinho de XP
  8. 8. desenvolvimento de software processo tradicional um pouquinho de XP Testes
  9. 9. desenvolvimento de software processo tradicional um pouquinho de XP Testes JUnit
  10. 10. O que é um Teste?
  11. 11. você entraria num avião...
  12. 12. ... que nunca saiu do chão? você entraria num avião...
  13. 13. ta maluco?
  14. 14. e por que você entrega software sem testar?
  15. 15. como você desenvolve software hoje?
  16. 16. Code and fix!
  17. 17. O processo tradicional • Sem metodologia de desenvolvimento • Procedural e estruturada • Grande dificuldade para mostrar e simular a relação entre o código (entidades) e o negócio [Cristiano Milfont]
  18. 18. Unificação de Processos
  19. 19. • Criação de processos unificados (*UP) • Direcionados a casos de uso • Centrados na arquitetura • Iterativos e incrementais • Utilização da linguagem UML • Fases bem definidas, como na engenharia civil • Concepção, elaboração, construção e transição [Cristiano Milfont]
  20. 20. Inspirado em outras engenharias Quase sempre a civil
  21. 21. Inspirado em outras engenharias Quase sempre a civil
  22. 22. Inspirado em outras engenharias Quase sempre a civil
  23. 23. Dá pra afastar um pouquinho?
  24. 24. Custo de mudanças
  25. 25. BDUF big design up front
  26. 26. BDUF big design up front is evil!
  27. 27. nós estamos jogando com as regras erradas!
  28. 28. “A maioria das nossas suposições sobre negócios, tecnologia e organizações têm pelo menos 50 anos. Elas tem sobrevivido ao seu tempo. Como resultado, estamos pregando, ensinando, e praticando políticas que estão cada vez mais desalinhadas com a realidade, e são contra produtivas.” Peter Drucker (1909-2005)
  29. 29. Não é assim que se faz software
  30. 30. Não é assim que se faz software Acredite!
  31. 31. Manifesto Ágil Estamos descobrindo maneiras melhores de desenvolver software fazendo-o nós mesmos e ajudando outros a fazê-lo. Através deste trabalho, passamos a valorizar: Indivíduos e interação entre eles mais que processos e ferramentas Software em funcionamento 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 Ou seja, mesmo havendo valor nos itens à direita, valorizamos mais os itens à esquerda. Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn,Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas ©2001, Autores acima citados. Esta declaração pode ser livremente copiada, sob qualquer forma,mas apenas na sua totalidade através do presente aviso.
  32. 32. XP Extreme Programming
  33. 33. O que é XP?
  34. 34. Utilização de funcionalidades de software Às vezes Frequentemente 16% 13% Sempre 7% Raramente 19% Nunca 45%
  35. 35. desperdício Raramente 19% Nunca 45%
  36. 36. Pareto Frequentemente 13% Sempre 7% 20% das funcionalidades geram 80% do valor
  37. 37. XP é a arte de maximizar a quantidade de software que você não vai fazer Vinícius Manhães Teles - ImproveIt
  38. 38. Extreme Programming É um conjunto de princípios, valores e práticas
  39. 39. Onde...
  40. 40. Onde... ... os princípios conectam os valores às práticas
  41. 41. • O XP é uma metodologia rigorosa e disciplinada que requer o cumprimento de suas práticas para o sucesso na adoção. • O XP pode ser usado com CMM e UPs. • A preocupação não é com qualidade (que deve natural) e sim com a saúde do sistema (segundo Kent Beck). [Cristiano Milfont]
  42. 42. e testes vão me salvar?
  43. 43. testes evitarão falhas? e testes vão me salvar?
  44. 44. falhas existem [1] [2]
  45. 45. 1/3 poderiam ser evitadas falhas existem [1] [2]
  46. 46. 1/3 poderiam ser evitadas 50% falhas existem são detectadas em produção [1] [2]
  47. 47. 1/3 poderiam ser evitadas 50% falhas existem são detectadas em produção U$60 bi ano custam caro! [1] [2]
  48. 48. bug
  49. 49. bug feature
  50. 50. defeitos são caros! quanto mais tarde forem encontrados, mais caros serão
  51. 51. conclusão: é melhor encontrar os defeitos o mais cedo possível!
  52. 52. depois eu testo
  53. 53. estou sem tempo
  54. 54. funcionou!?
  55. 55. funcionou!?
  56. 56. seja profissional garanta o seu trabalho!
  57. 57. você é o único responsável pela qualidade do seu trabalho
  58. 58. ninguém melhora se você não melhorar primeiro!
  59. 59. programadores profissionais escrevem testes. [3]
  60. 60. teste tudo antes - TDD
  61. 61. quando você terminar
  62. 62. quando você terminar é porque você realmente terminou
  63. 63. quando você terminar é porque você realmente terminou
  64. 64. escreva os testes antes!
  65. 65. você vai
  66. 66. você vai amar seus códigos
  67. 67. você vai amar seus códigos programar melhor
  68. 68. você vai amar seus códigos programar melhor pensar antes de escrever
  69. 69. você vai amar seus códigos programar melhor pensar antes de escrever reduzir código inútil
  70. 70. você vai amar seus códigos programar melhor pensar antes de escrever reduzir código inútil ganhar com qualidade
  71. 71. “Sempre que estiver tentado a escrever um print() ou uma expressão de depuração, escreva um teste” -- Martin Fowler
  72. 72. entre no ritmo
  73. 73. stand-up meeting @ 09:00h monte seu par escreva um teste codifique para passar no teste refatore entregar Ir para casa @ 17:00h
  74. 74. red
  75. 75. escreva um teste que não funciona red
  76. 76. green
  77. 77. escreva código que passe no teste green
  78. 78. refactor
  79. 79. refatore, recomece e refatore. Sempre! refactor
  80. 80. testes de unidade
  81. 81. testes de unidade teste todo seu código
  82. 82. testes de unidade teste todo seu código por partes
  83. 83. testes de unidade teste todo seu código por partes isoladas
  84. 84. testes de unidade teste todo seu código por partes isoladas e independentes
  85. 85. testes de unidade
  86. 86. testes de unidade evitam bugs
  87. 87. testes de unidade evitam bugs permitem fáceis alterações (coragem)
  88. 88. testes de unidade evitam bugs permitem fáceis alterações (coragem) documenta
  89. 89. testes de unidade evitam bugs permitem fáceis alterações (coragem) documenta serve como métrica do projeto
  90. 90. testes de unidade evitam bugs permitem fáceis alterações (coragem) documenta serve como métrica do projeto - testes == requisitos
  91. 91. rode os testes todo o tempo
  92. 92. rode os testes todo o tempo é melhor corrigir dois ou três probleminhas
  93. 93. rode os testes todo o tempo é melhor corrigir dois ou três probleminhas do que corrigir um problemão
  94. 94. mantenha tudo simples
  95. 95. mantenha tudo simples deixe os ‘complexos’ por último
  96. 96. mantenha tudo simples deixe os ‘complexos’ por último seja criativo
  97. 97. mantenha tudo simples deixe os ‘complexos’ por último seja criativo mantenha o foco
  98. 98. mantenha tudo simples deixe os ‘complexos’ por último seja criativo mantenha o foco use dados suficientes
  99. 99. mantenha tudo simples deixe os ‘complexos’ por último seja criativo mantenha o foco use dados suficientes - se 3 condições bastam, pra que 10?
  100. 100. achou um bug?
  101. 101. não o conserte antes de ter um teste que o reproduza achou um bug?
  102. 102. não o conserte antes de ter um teste que o reproduza achou um bug? ou então ele volta!
  103. 103. JUnit
  104. 104. framework que facilita o desenvolvimento e execução de testes de unidade em Java fornece uma API para criar os testes e aplicações para executa-los
  105. 105. escrito originalmente por Erich Gamma e Kent Beck parte de uma família de arquitetura de testes conhecida como xUnit
  106. 106. pra que um framework?
  107. 107. pra que um framework? verifica toda unidade de código
  108. 108. pra que um framework? verifica toda unidade de código facilita a criação
  109. 109. pra que um framework? verifica toda unidade de código facilita a criação facilita a automatização
  110. 110. pra que um framework? verifica toda unidade de código facilita a criação facilita a automatização é OO, gratuito, Open Source ...
  111. 111. JUnit 4 ficou muito simples
  112. 112. @Test anote seu método não precisa mais do prefixo test suas classes não precisam estender TestCase
  113. 113. @Before e @After anote seus métodos que serão o setUp e tearDown @BeforeClass e @AfterClass anote seus métodos que serão o setUp e tearDown em nível de classe
  114. 114. Exceptions @Test(expected = ArithmeticException.class) @Ignore @Ignore(“Não pode ser executado ainda.”) @Test
  115. 115. Timeout @Test(timeout = 1000)
  116. 116. o ritual
  117. 117. saiba o vai implementar
  118. 118. saiba o vai implementar liste tudo que deve ser feito
  119. 119. saiba o vai implementar liste tudo que deve ser feito escreva um teste antes para qualquer tarefa listada
  120. 120. saiba o vai implementar liste tudo que deve ser feito escreva um teste antes para qualquer tarefa listada certifique-se que o teste falhe
  121. 121. implemente
  122. 122. implemente implemente um código simples para passar no teste
  123. 123. implemente implemente um código simples para passar no teste refatore o teste e depois o código
  124. 124. implemente implemente um código simples para passar no teste refatore o teste e depois o código recomece
  125. 125. alguns lembretes
  126. 126. alguns lembretes assertEquals
  127. 127. alguns lembretes assertEquals - testa igualdade (esperado x retornado)
  128. 128. alguns lembretes assertEquals - testa igualdade (esperado x retornado) assertTrue
  129. 129. alguns lembretes assertEquals - testa igualdade (esperado x retornado) assertTrue - testa o retorno ‘true’
  130. 130. alguns lembretes assertEquals - testa igualdade (esperado x retornado) assertTrue - testa o retorno ‘true’ assertFalse
  131. 131. alguns lembretes assertEquals - testa igualdade (esperado x retornado) assertTrue - testa o retorno ‘true’ assertFalse - testa o retorno ‘false’
  132. 132. alguns lembretes
  133. 133. alguns lembretes assertNull
  134. 134. alguns lembretes assertNull - testa se um valor é nulo
  135. 135. alguns lembretes assertNull - testa se um valor é nulo assertNotNull
  136. 136. alguns lembretes assertNull - testa se um valor é nulo assertNotNull - testa se um valor não é nulo
  137. 137. hands on!
  138. 138. dúvidas?
  139. 139. http://www.esjug.org
  140. 140. Referências • Fotos • ImproveIt - http://www.improveit.com.br • Pesquisas • [1] - NIST - http://www.nist.gov/public_affairs/releases/n02-10.htm • [2] - ImproveIt - http://www.improveit.com.br/xp/praticas/tdd • [3] – Fragmental - Shoes - http://blog.fragmental.com.br/2007/10/31/programadoresprofissionais-escrevem-testes- ponto-final • Materiais • Extreme Programming - http://extremeprogramming.org • Igor Macaubas e Marcos Pereira - http://www.slideshare.net/macaubas/seminario-scrum-presentation • ImproveIt - http://www.improveit.com.br/scrum • ImproveIt - http://www.improveit.com.br/xp • Manifesto Ágil - http://manifestoagil.com.br • Guilherme Chapiewski - http://www.slideshare.net/gchapiewski/desenvolvimento-gil-com-xp-e-scrum-presentation • André Faria Gomes - http://andrefaria.com/2008/08/22/junit-4-em-60-segundos • Cristiano Milfont - http://www.slideshare.net/cmilfont/extreme-programming-148802
  141. 141. Obrigado! podem acordar
  142. 142. Testes de Unidade com JUnit Paulo César M. Jeveaux paulo.jeveaux@giran.com.br

×