Importância dos testes automatizadoss

1,996 views
1,923 views

Published on

Desenvolver software é uma luta contra complexidade. Cada linha de código que um programador escreve pode ser mais um ponto de falha no software. Para diminuir os riscos é fundamental que o programador e a equipe adotem uma cultura na escrita de testes, de preferência automatizados, para garantir que o software se comporte como esperado durante todo o ciclo de vida do desenvolvimento. Nesta apresentação explanarei a importância dos testes automatizados de acordo com a cultura ágil, os tipos de testes que podemos escrever, os benefícios obtidos a médio e longo prazo, e as dificuldades ao escreve-los. Será também apresentado algumas ferramentas úteis e relatos da minha experiência na escrita de testes no mercado de trabalho

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

No Downloads
Views
Total views
1,996
On SlideShare
0
From Embeds
0
Number of Embeds
7
Actions
Shares
0
Downloads
42
Comments
0
Likes
4
Embeds 0
No embeds

No notes for slide

Importância dos testes automatizadoss

  1. 1. A importância dos testes automatizados Rafael Ponte @rponteTuesday, October 18, 2011
  2. 2. @rponteTuesday, October 18, 2011
  3. 3. Tuesday, October 18, 2011
  4. 4. antes de começarmos...Tuesday, October 18, 2011
  5. 5. quem aqui já programa?Tuesday, October 18, 2011
  6. 6. quem aqui já programa? Java? .Net? Ruby? PhP? C? Pascal?Tuesday, October 18, 2011
  7. 7. e quem já trabalha na área?Tuesday, October 18, 2011
  8. 8. e quem escreve testes?Tuesday, October 18, 2011
  9. 9. eu conheço alguém que escreve...Tuesday, October 18, 2011
  10. 10. eu conheço alguém que escreve... e acho que muitos aqui também já o conhecemTuesday, October 18, 2011
  11. 11. @yuriadams O garoto prodígio dos testes.Tuesday, October 18, 2011
  12. 12. Tuesday, October 18, 2011
  13. 13. Tuesday, October 18, 2011
  14. 14. Tuesday, October 18, 2011
  15. 15. ME MATA DE ORGULHO!Tuesday, October 18, 2011
  16. 16. desenvolver software é uma luta contra complexidadeTuesday, October 18, 2011
  17. 17. toda linha de código que escrevemos pode ser um ponto de falhaTuesday, October 18, 2011
  18. 18. toda linha de código que escrevemos pode ser um ponto de falha críticoTuesday, October 18, 2011
  19. 19. estudamos e aplicamos práticas para tentarmos diminuir estes riscosTuesday, October 18, 2011
  20. 20. testarTuesday, October 18, 2011
  21. 21. por que testar?Tuesday, October 18, 2011
  22. 22. para verificar se o sistema se comporta como deveriaTuesday, October 18, 2011
  23. 23. como testar? testes manuais. testes automatizados.Tuesday, October 18, 2011
  24. 24. testes manuaisTuesday, October 18, 2011
  25. 25. $ão caros $ requer pessoal qualificado $ requer tempo $ requer documentação $ repetitivos e cansativosTuesday, October 18, 2011
  26. 26. o que aprendemos com desenvolvimento de software é que...Tuesday, October 18, 2011
  27. 27. tudo que depende do homem e é repetitivo está sujeito a falhasTuesday, October 18, 2011
  28. 28. por isso nós automatizamos! :-)Tuesday, October 18, 2011
  29. 29. testes automatizadosTuesday, October 18, 2011
  30. 30. um programinha para testar outro programinhaTuesday, October 18, 2011
  31. 31. testes te trazem confiança e segurança para... > implementar novas features > achar e corrigir bugs > refatorar código > refatorar código dos outrosTuesday, October 18, 2011
  32. 32. CONFIANÇATuesday, October 18, 2011
  33. 33. os testes te permitem ter... > menor incidência de bugs > feedback rápido do que funciona > regressão de código > produtividade > melhor design do código > documentação executávelTuesday, October 18, 2011
  34. 34. tipos de testes testes de unidade testes de integração testes de aceitaçãoTuesday, October 18, 2011
  35. 35. testes de unidade menor unidade de código executávelTuesday, October 18, 2011
  36. 36. menor unidade na = método POOTuesday, October 18, 2011
  37. 37. teste de teste = unidade unitárioTuesday, October 18, 2011
  38. 38. testes de unidade normalmente são: > mais fáceis de escrever; > muito rápidos para rodar; > mais fáceis para rastrear erros;Tuesday, October 18, 2011
  39. 39. que tal rodar centenas ou milhares de testes em segundos?Tuesday, October 18, 2011
  40. 40. feedback quase que instantâneo! WOW!Tuesday, October 18, 2011
  41. 41. testes de integração seu código integrado ao banco de dados, rede, disco etcTuesday, October 18, 2011
  42. 42. valida os componentes de software funcionando juntosTuesday, October 18, 2011
  43. 43. valida os componentes de software funcionando juntos teste de “maxu” vai no banco de dados! Yuri AdamsTuesday, October 18, 2011
  44. 44. e assim como os testes de unidade...Tuesday, October 18, 2011
  45. 45. testes de integração normalmente são: > mais fáceis de escrever; > muito rápidos para rodar; > mais fáceis para rastrear erros;Tuesday, October 18, 2011
  46. 46. feedback AINDA quase que instantâneoTuesday, October 18, 2011
  47. 47. testes de aceitação o que o usuário espera que aconteçaTuesday, October 18, 2011
  48. 48. testeTuesday, October 18, 2011
  49. 49. teste endTuesday, October 18, 2011
  50. 50. teste end toTuesday, October 18, 2011
  51. 51. teste end to endTuesday, October 18, 2011
  52. 52. valida o software na perspectiva do usuárioTuesday, October 18, 2011
  53. 53. valida o software na perspectiva do usuárioTuesday, October 18, 2011
  54. 54. valida o software na perspectiva do usuárioTuesday, October 18, 2011
  55. 55. testes de aceitação normalmente são: > trabalhosos para escrever; > lentos para rodar; > difíceis para rastrear erros; > frágeisTuesday, October 18, 2011
  56. 56. apesar da dificuldade para escrevê-los...Tuesday, October 18, 2011
  57. 57. apesar da dificuldade para escrevê-los... Aceite os testes de aceitação!! Handerson FrotaTuesday, October 18, 2011
  58. 58. apesar da dificuldade para escrevê-los... Aceite os testes de aceitação!! ainda assim vale a pena! Handerson FrotaTuesday, October 18, 2011
  59. 59. resumindo...Tuesday, October 18, 2011
  60. 60. como tudo isso vai numa app real?Tuesday, October 18, 2011
  61. 61. Tuesday, October 18, 2011
  62. 62. browser banco de dados app (servidor)Tuesday, October 18, 2011
  63. 63. teste de unidadeTuesday, October 18, 2011
  64. 64. teste de integraçãoTuesday, October 18, 2011
  65. 65. teste de aceitaçãoTuesday, October 18, 2011
  66. 66. teste de unidade teste de aceitação teste de integraçãoTuesday, October 18, 2011
  67. 67. qual o melhor?Tuesday, October 18, 2011
  68. 68. unidade > integração ?Tuesday, October 18, 2011
  69. 69. nãoTuesday, October 18, 2011
  70. 70. integração > aceitação ?Tuesday, October 18, 2011
  71. 71. nãoTuesday, October 18, 2011
  72. 72. aceitação > unidade ?Tuesday, October 18, 2011
  73. 73. nãoTuesday, October 18, 2011
  74. 74. depende?Tuesday, October 18, 2011
  75. 75. simTuesday, October 18, 2011
  76. 76. depende da tua necessidadeTuesday, October 18, 2011
  77. 77. depende da tua necessidade teste de aceitação testa TUDO.Handerson FrotaTuesday, October 18, 2011
  78. 78. teste de integração é teste de “maxu”. depende da tua Yuri Adams necessidade teste de aceitação testa TUDO.Handerson FrotaTuesday, October 18, 2011
  79. 79. mas no geral, siga a pirâmideTuesday, October 18, 2011
  80. 80. Test Automation Pyramid Aceitação - 10% Integração - 40% Unidade - 50%Tuesday, October 18, 2011
  81. 81. que tal um pouco de prática, né?Tuesday, October 18, 2011
  82. 82. de maneira não automatizadaTuesday, October 18, 2011
  83. 83. problema: calcular fatorial de um número 4! = 4.3.2.1 = 24Tuesday, October 18, 2011
  84. 84. 1! ==> 1 2! ==> 2 3! ==> 6 ...Tuesday, October 18, 2011
  85. 85. 4! = 4.3.2.1 = 24 “com um algoritimo recursivo eu resolvo isso fácil antes da novela das 7h”Tuesday, October 18, 2011
  86. 86. Uma função recursiva é uma função que se refere a si própriaTuesday, October 18, 2011
  87. 87. Tuesday, October 18, 2011
  88. 88. como testar o código?Tuesday, October 18, 2011
  89. 89. 1! ==> 1 2! ==> 2 3! ==> 6 ...Tuesday, October 18, 2011
  90. 90. você escreve uma classe de teste “meia-boca”Tuesday, October 18, 2011
  91. 91. depois roda a classe de teste na linha de comandoTuesday, October 18, 2011
  92. 92. depois roda a classe de teste na linha de comando para ver o resultado!Tuesday, October 18, 2011
  93. 93. você testa mais um pouco...Tuesday, October 18, 2011
  94. 94. e roda mais uma vez para ver o resultado...Tuesday, October 18, 2011
  95. 95. altera mais um pouco, roda mais um pouco, verifica o resultado, corrige aqui, corrige ali, roda de novo, ...Tuesday, October 18, 2011
  96. 96. e depois que tudo funciona como esperado...Tuesday, October 18, 2011
  97. 97. zipa e envia pro professor, né?Tuesday, October 18, 2011
  98. 98. zipa e envia pro professor, né? ainda não!!Tuesday, October 18, 2011
  99. 99. zipa e envia pro professor, né? falta apagar a classe “meia-boca” de teste!Tuesday, October 18, 2011
  100. 100. agora sim! zipa e envia pro professor!Tuesday, October 18, 2011
  101. 101. agora sim! zipa e envia pro professor! com cópia pra mim também! ;D SérgioTuesday, October 18, 2011
  102. 102. PRONTO!Tuesday, October 18, 2011
  103. 103. facinho, né?Tuesday, October 18, 2011
  104. 104. agora você pode jogar Starcraft II em paz!Tuesday, October 18, 2011
  105. 105. ouTuesday, October 18, 2011
  106. 106. jogar XBox com seus amigos descoladosTuesday, October 18, 2011
  107. 107. eu me pergunto...Tuesday, October 18, 2011
  108. 108. e depois de todo esse esforço...Tuesday, October 18, 2011
  109. 109. e depois de todo esse esforço... você DESCARTA sua classe de teste?Tuesday, October 18, 2011
  110. 110. e depois de todo esse esforço... e daí? Sérgio você DESCARTA sua classe de teste?Tuesday, October 18, 2011
  111. 111. e depois de todo esse esforço... o que importa é o programa e daí? rodando! Sérgio você DESCARTA sua classe de teste?Tuesday, October 18, 2011
  112. 112. e depois de todo esse esforço... o que importa é mexer nesse nunca maisevou o programa daí? códigorodando! mesmo de novo Sérgio você DESCARTA sua classe de teste?Tuesday, October 18, 2011
  113. 113. mas na vida real não é bem assim...Tuesday, October 18, 2011
  114. 114. você mantém o código até que o software “morra”Tuesday, October 18, 2011
  115. 115. um software não morre...Tuesday, October 18, 2011
  116. 116. um software não morre... até queTuesday, October 18, 2011
  117. 117. um software não morre... até que você tire ele de produção,Tuesday, October 18, 2011
  118. 118. um software não morre... até que você tire ele de produção, você apague todo o código fonteTuesday, October 18, 2011
  119. 119. um software não morre... até que você tire ele de produção, você apague todo o código fonte você apague o banco de dadosTuesday, October 18, 2011
  120. 120. um software não morre... até que você tire ele de produção, você apague todo o código fonte você apague o banco de dados você mate os programadores, mate os analistas e o arquitetoTuesday, October 18, 2011
  121. 121. um software não morre... até que você tire ele de produção, você apague todo o código fonte você apague o banco de dados você mate os programadores, mate os analistas e o arquiteto e você queime o backup e documentaçãoTuesday, October 18, 2011
  122. 122. mas pro seu azar...Tuesday, October 18, 2011
  123. 123. suponha que seu professor queira um algoritimo não-recursivoTuesday, October 18, 2011
  124. 124. suponha que seu professor queira um algoritimo não-recursivo #comofasTuesday, October 18, 2011
  125. 125. 1. você vai ter que estudar o problema de novoTuesday, October 18, 2011
  126. 126. 2. você tem que alterar o código atual de novoTuesday, October 18, 2011
  127. 127. 3. você vai ter que testa-lo de novoTuesday, October 18, 2011
  128. 128. mas cadê minha classe de teste?Tuesday, October 18, 2011
  129. 129. eu apagueeeeeiiii?Tuesday, October 18, 2011
  130. 130. Tuesday, October 18, 2011
  131. 131. que tal fazermos do jeito certo?Tuesday, October 18, 2011
  132. 132. que tal fazermos do jeito certo? com testes automatizadosTuesday, October 18, 2011
  133. 133. jUnit assertEquals(expected, actual);Tuesday, October 18, 2011
  134. 134. jUnit assertEquals(4, 2+2);Tuesday, October 18, 2011
  135. 135. jUnit assertEquals(7, 10-4);Tuesday, October 18, 2011
  136. 136. vamos testarTuesday, October 18, 2011
  137. 137. implementação recursivaTuesday, October 18, 2011
  138. 138. primeiro caso de teste 1! ==> 1Tuesday, October 18, 2011
  139. 139. você escreve o teste com jUnitTuesday, October 18, 2011
  140. 140. depois roda o teste...Tuesday, October 18, 2011
  141. 141. mais alguns casos de teste... 2! ==> 2 3! ==> 6 4! ==> 24 5! ==> 120Tuesday, October 18, 2011
  142. 142. escreva os casos de teste...Tuesday, October 18, 2011
  143. 143. roda mais uma vez...Tuesday, October 18, 2011
  144. 144. um caso esquecido... 0! ==> 1 1! ==> 1Tuesday, October 18, 2011
  145. 145. não me escapa...Tuesday, October 18, 2011
  146. 146. roda mais uma vez...Tuesday, October 18, 2011
  147. 147. PRONTO! agora você pode escrever o algoritimo não-recursivoTuesday, October 18, 2011
  148. 148. #greenbar refatora ==> roda os testesTuesday, October 18, 2011
  149. 149. facinho, né?Tuesday, October 18, 2011
  150. 150. primeiro escreve o código da implementação, depois escreve o de teste... LEGAL!Tuesday, October 18, 2011
  151. 151. e se fosse possível escrever o teste ANTES da implementação?Tuesday, October 18, 2011
  152. 152. ahn?Tuesday, October 18, 2011
  153. 153. TDD Test Driven DevelopmentTuesday, October 18, 2011
  154. 154. é assim que eu evoluo minha aplicação de forma contínua TDD Test Driven DevelopmentTuesday, October 18, 2011
  155. 155. é assim que eu evoluo minha aplicação de eu falei sobre isso aqui ontem, ué! forma contínua TDD Test Driven DevelopmentTuesday, October 18, 2011
  156. 156. step by stepTuesday, October 18, 2011
  157. 157. TDD = testesTuesday, October 18, 2011
  158. 158. não TDD = testesTuesday, October 18, 2011
  159. 159. TDD é sobre DESIGN e MODELAGEM de códigoTuesday, October 18, 2011
  160. 160. a bateria de testes é um brindeTuesday, October 18, 2011
  161. 161. CULTURA DE TESTES casos e casosTuesday, October 18, 2011
  162. 162. Tuesday, October 18, 2011
  163. 163. Tuesday, October 18, 2011
  164. 164. Tuesday, October 18, 2011
  165. 165. NEM TUDO SÃO FLORES Depois de +2 anos escrevendo testes.Tuesday, October 18, 2011
  166. 166. primeiro passo na consultoriaTuesday, October 18, 2011
  167. 167. Convencer a gerência. Seria um investimento de médio-longo prazo.Tuesday, October 18, 2011
  168. 168. Projeto já em andamento. Dificuldade para escrever testes.Tuesday, October 18, 2011
  169. 169. Infra? Não tínhamos nada pronto!Tuesday, October 18, 2011
  170. 170. Colaboração da equipe. Equipe de bons desenvolvedores, mas sem experiência com testes.Tuesday, October 18, 2011
  171. 171. Zona de ConfortoTuesday, October 18, 2011
  172. 172. Devs. simpatizantes. Teste de integração é teste de “maxu”!Tuesday, October 18, 2011
  173. 173. Testes mal escritos. Você vai escrevê-los, pode ter certeza disso.Tuesday, October 18, 2011
  174. 174. TDD. Somente em regras de negócio complexas.Tuesday, October 18, 2011
  175. 175. OOP e SOLID Principles Sem estes conhecimentos não é tão simples ter um bom design.Tuesday, October 18, 2011
  176. 176. Testes de Aceitação. Tudo ia bem, até o dia em que o número de testes cresceu demais.Tuesday, October 18, 2011
  177. 177. Testando cenários importantes. Começamos do jeito certo.Tuesday, October 18, 2011
  178. 178. Test Automation Pyramid Aceitação - 10% Integração - 40% Unidade - 50%Tuesday, October 18, 2011
  179. 179. More, more... Testes com granularidade fina demais.Tuesday, October 18, 2011
  180. 180. Test Automation Pyramid Square Aceitação - 30% Integração - 30% Unidade - 40%Tuesday, October 18, 2011
  181. 181. Mantê-los se tornou caro. Frágeis, feedback demorado, falsos negativos e difícil rastrear erros.Tuesday, October 18, 2011
  182. 182. Nos tornamos mais criteriosos.Tuesday, October 18, 2011
  183. 183. IMPACTO Depois de +2 anos escrevendo testes.Tuesday, October 18, 2011
  184. 184. PRODUTIVIDADE. Baixa no início. Melhora durante os Sprints.Tuesday, October 18, 2011
  185. 185. Qualidade no software. Menor incidência de bugs e correções rápidas.Tuesday, October 18, 2011
  186. 186. De 100% para 25%. Melhoramos nossas estimativas.Tuesday, October 18, 2011
  187. 187. Gerência. Satisfeita com a produtividade de alguns projetos, decepcionada com outros.Tuesday, October 18, 2011
  188. 188. Equipe mais madura. Perceberam a importância real dos testes.Tuesday, October 18, 2011
  189. 189. CONCLUSÃOTuesday, October 18, 2011
  190. 190. Você só percebe os benefícios dos testes entre 6 meses e 1 anoTuesday, October 18, 2011
  191. 191. não existe uma receita de bolo para desenvolver softwareTuesday, October 18, 2011
  192. 192. mas sim um conjunto de princípios e práticas que podem te ajudar a desenvolver melhorTuesday, October 18, 2011
  193. 193. permita que sua equipe trabalhe melhorTuesday, October 18, 2011
  194. 194. permita que sua empresa entregue software melhorTuesday, October 18, 2011
  195. 195. permita-se ser um profissional melhorTuesday, October 18, 2011
  196. 196. use testes automatizadosTuesday, October 18, 2011
  197. 197. testes automatizados eu aprovo!Tuesday, October 18, 2011
  198. 198. Rafael Ponte rponte@triadworks.com.brTuesday, October 18, 2011

×