Palestra Testes De Unidade Com JUnit

Loading...

Flash Player 9 (or above) is needed to view presentations.
We have detected that you do not have it on your computer. To install it, go here.

0 comments

Post a comment

    Post a comment
    Embed Video
    Edit your comment Cancel

    1 Favorite

    Palestra Testes De Unidade Com JUnit - Presentation Transcript

    1. Testes de Unidade com JUnit Paulo César M. Jeveaux paulo.jeveaux@giran.com.br
    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. 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. Sobre o que vamos falar hoje...
    5. desenvolvimento de software
    6. desenvolvimento de software processo tradicional
    7. desenvolvimento de software processo tradicional um pouquinho de XP
    8. desenvolvimento de software processo tradicional um pouquinho de XP Testes
    9. desenvolvimento de software processo tradicional um pouquinho de XP Testes JUnit
    10. O que é um Teste?
    11. você entraria num avião...
    12. ... que nunca saiu do chão? você entraria num avião...
    13. ta maluco?
    14. e por que você entrega software sem testar?
    15. como você desenvolve software hoje?
    16. Code and fix!
    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. Unificação de Processos
    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. Inspirado em outras engenharias Quase sempre a civil
    21. Inspirado em outras engenharias Quase sempre a civil
    22. Inspirado em outras engenharias Quase sempre a civil
    23. Dá pra afastar um pouquinho?
    24. Custo de mudanças
    25. BDUF big design up front
    26. BDUF big design up front is evil!
    27. nós estamos jogando com as regras erradas!
    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. Não é assim que se faz software
    30. Não é assim que se faz software Acredite!
    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. XP Extreme Programming
    33. O que é XP?
    34. Utilização de funcionalidades de software Às vezes Frequentemente 16% 13% Sempre 7% Raramente 19% Nunca 45%
    35. desperdício Raramente 19% Nunca 45%
    36. Pareto Frequentemente 13% Sempre 7% 20% das funcionalidades geram 80% do valor
    37. XP é a arte de maximizar a quantidade de software que você não vai fazer Vinícius Manhães Teles - ImproveIt
    38. Extreme Programming É um conjunto de princípios, valores e práticas
    39. Onde...
    40. Onde... ... os princípios conectam os valores às práticas
    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. e testes vão me salvar?
    43. testes evitarão falhas? e testes vão me salvar?
    44. falhas existem [1] [2]
    45. 1/3 poderiam ser evitadas falhas existem [1] [2]
    46. 1/3 poderiam ser evitadas 50% falhas existem são detectadas em produção [1] [2]
    47. 1/3 poderiam ser evitadas 50% falhas existem são detectadas em produção U$60 bi ano custam caro! [1] [2]
    48. bug
    49. bug feature
    50. defeitos são caros! quanto mais tarde forem encontrados, mais caros serão
    51. conclusão: é melhor encontrar os defeitos o mais cedo possível!
    52. depois eu testo
    53. estou sem tempo
    54. funcionou!?
    55. funcionou!?
    56. seja profissional garanta o seu trabalho!
    57. você é o único responsável pela qualidade do seu trabalho
    58. ninguém melhora se você não melhorar primeiro!
    59. programadores profissionais escrevem testes. [3]
    60. teste tudo antes - TDD
    61. quando você terminar
    62. quando você terminar é porque você realmente terminou
    63. quando você terminar é porque você realmente terminou
    64. escreva os testes antes!
    65. você vai
    66. você vai amar seus códigos
    67. você vai amar seus códigos programar melhor
    68. você vai amar seus códigos programar melhor pensar antes de escrever
    69. você vai amar seus códigos programar melhor pensar antes de escrever reduzir código inútil
    70. você vai amar seus códigos programar melhor pensar antes de escrever reduzir código inútil ganhar com qualidade
    71. “Sempre que estiver tentado a escrever um print() ou uma expressão de depuração, escreva um teste” -- Martin Fowler
    72. entre no ritmo
    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. red
    75. escreva um teste que não funciona red
    76. green
    77. escreva código que passe no teste green
    78. refactor
    79. refatore, recomece e refatore. Sempre! refactor
    80. testes de unidade
    81. testes de unidade teste todo seu código
    82. testes de unidade teste todo seu código por partes
    83. testes de unidade teste todo seu código por partes isoladas
    84. testes de unidade teste todo seu código por partes isoladas e independentes
    85. testes de unidade
    86. testes de unidade evitam bugs
    87. testes de unidade evitam bugs permitem fáceis alterações (coragem)
    88. testes de unidade evitam bugs permitem fáceis alterações (coragem) documenta
    89. testes de unidade evitam bugs permitem fáceis alterações (coragem) documenta serve como métrica do projeto
    90. testes de unidade evitam bugs permitem fáceis alterações (coragem) documenta serve como métrica do projeto - testes == requisitos
    91. rode os testes todo o tempo
    92. rode os testes todo o tempo é melhor corrigir dois ou três probleminhas
    93. rode os testes todo o tempo é melhor corrigir dois ou três probleminhas do que corrigir um problemão
    94. mantenha tudo simples
    95. mantenha tudo simples deixe os ‘complexos’ por último
    96. mantenha tudo simples deixe os ‘complexos’ por último seja criativo
    97. mantenha tudo simples deixe os ‘complexos’ por último seja criativo mantenha o foco
    98. mantenha tudo simples deixe os ‘complexos’ por último seja criativo mantenha o foco use dados suficientes
    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. achou um bug?
    101. não o conserte antes de ter um teste que o reproduza achou um bug?
    102. não o conserte antes de ter um teste que o reproduza achou um bug? ou então ele volta!
    103. JUnit
    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. escrito originalmente por Erich Gamma e Kent Beck parte de uma família de arquitetura de testes conhecida como xUnit
    106. pra que um framework?
    107. pra que um framework? verifica toda unidade de código
    108. pra que um framework? verifica toda unidade de código facilita a criação
    109. pra que um framework? verifica toda unidade de código facilita a criação facilita a automatização
    110. pra que um framework? verifica toda unidade de código facilita a criação facilita a automatização é OO, gratuito, Open Source ...
    111. JUnit 4 ficou muito simples
    112. @Test anote seu método não precisa mais do prefixo test suas classes não precisam estender TestCase
    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. Exceptions @Test(expected = ArithmeticException.class) @Ignore @Ignore(“Não pode ser executado ainda.”) @Test
    115. Timeout @Test(timeout = 1000)
    116. o ritual
    117. saiba o vai implementar
    118. saiba o vai implementar liste tudo que deve ser feito
    119. saiba o vai implementar liste tudo que deve ser feito escreva um teste antes para qualquer tarefa listada
    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. implemente
    122. implemente implemente um código simples para passar no teste
    123. implemente implemente um código simples para passar no teste refatore o teste e depois o código
    124. implemente implemente um código simples para passar no teste refatore o teste e depois o código recomece
    125. alguns lembretes
    126. alguns lembretes assertEquals
    127. alguns lembretes assertEquals - testa igualdade (esperado x retornado)
    128. alguns lembretes assertEquals - testa igualdade (esperado x retornado) assertTrue
    129. alguns lembretes assertEquals - testa igualdade (esperado x retornado) assertTrue - testa o retorno ‘true’
    130. alguns lembretes assertEquals - testa igualdade (esperado x retornado) assertTrue - testa o retorno ‘true’ assertFalse
    131. alguns lembretes assertEquals - testa igualdade (esperado x retornado) assertTrue - testa o retorno ‘true’ assertFalse - testa o retorno ‘false’
    132. alguns lembretes
    133. alguns lembretes assertNull
    134. alguns lembretes assertNull - testa se um valor é nulo
    135. alguns lembretes assertNull - testa se um valor é nulo assertNotNull
    136. alguns lembretes assertNull - testa se um valor é nulo assertNotNull - testa se um valor não é nulo
    137. hands on!
    138. dúvidas?
    139. http://www.esjug.org
    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. Obrigado! podem acordar
    142. Testes de Unidade com JUnit Paulo César M. Jeveaux paulo.jeveaux@giran.com.br

    + Paulo César M. JeveauxPaulo César M. Jeveaux, 6 months ago

    custom

    970 views, 1 favs, 4 embeds more stats

    More info about this document

    CC Attribution-NonCommercial-ShareAlike LicenseCC Attribution-NonCommercial-ShareAlike LicenseCC Attribution-NonCommercial-ShareAlike License

    Go to text version

    • Total Views 970
      • 776 on SlideShare
      • 194 from embeds
    • Comments 0
    • Favorites 1
    • Downloads 63
    Most viewed embeds
    • 188 views on http://www.jeveaux.com
    • 3 views on http://static.slideshare.net
    • 2 views on http://feeds.feedburner.com
    • 1 views on http://en.wikipedia.org

    more

    All embeds
    • 188 views on http://www.jeveaux.com
    • 3 views on http://static.slideshare.net
    • 2 views on http://feeds.feedburner.com
    • 1 views on http://en.wikipedia.org

    less

    Flagged as inappropriate Flag as inappropriate
    Flag as inappropriate

    Select your reason for flagging this presentation as inappropriate. If needed, use the feedback form to let us know more details.

    Cancel
    File a copyright complaint
    Having problems? Go to our helpdesk?

    Categories