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
31. testes te trazem confiança e
segurança para...
> implementar novas features
> achar e corrigir bugs
> refatorar código
> refatorar código dos outros
Tuesday, October 18, 2011
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ável
Tuesday, October 18, 2011
34. tipos de testes
testes de unidade
testes de integração
testes de aceitação
Tuesday, October 18, 2011
35. testes de unidade
menor unidade de código
executável
Tuesday, October 18, 2011
36. menor
unidade na = método
POO
Tuesday, October 18, 2011
37. teste de teste
=
unidade unitário
Tuesday, October 18, 2011
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. que tal rodar centenas ou
milhares de testes em
segundos?
Tuesday, October 18, 2011
43. valida os componentes de
software funcionando juntos
teste de “maxu” vai no banco de
dados!
Yuri Adams
Tuesday, October 18, 2011
44. e assim como os testes
de unidade...
Tuesday, October 18, 2011
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
52. valida o software na perspectiva
do usuário
Tuesday, October 18, 2011
53. valida o software na perspectiva
do usuário
Tuesday, October 18, 2011
54. valida o software na perspectiva
do usuário
Tuesday, October 18, 2011
55. testes de aceitação
normalmente são:
> trabalhosos para escrever;
> lentos para rodar;
> difíceis para rastrear erros;
> frágeis
Tuesday, October 18, 2011
77. depende da tua
necessidade
teste de aceitação testa TUDO.
Handerson Frota
Tuesday, October 18, 2011
78. teste de integração é teste de
“maxu”.
depende da tua Yuri Adams
necessidade
teste de aceitação testa TUDO.
Handerson Frota
Tuesday, October 18, 2011
79. mas no geral, siga a
pirâmide
Tuesday, October 18, 2011
80. Test Automation Pyramid
Aceitação - 10%
Integração - 40%
Unidade - 50%
Tuesday, October 18, 2011
81. que tal um pouco de
prática, né?
Tuesday, October 18, 2011
108. e depois de todo esse
esforço...
Tuesday, October 18, 2011
109. e depois de todo esse
esforço...
você DESCARTA sua
classe de teste?
Tuesday, October 18, 2011
110. e depois de todo esse
esforço...
e daí?
Sérgio
você DESCARTA sua
classe de teste?
Tuesday, October 18, 2011
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. 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. mas na vida real não é
bem assim...
Tuesday, October 18, 2011
114. você mantém o código
até que o software
“morra”
Tuesday, October 18, 2011
117. um software não morre...
até que
você tire ele de produção,
Tuesday, October 18, 2011
118. um software não morre...
até que
você tire ele de produção,
você apague todo o código fonte
Tuesday, October 18, 2011
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 dados
Tuesday, October 18, 2011
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 arquiteto
Tuesday, October 18, 2011
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ção
Tuesday, October 18, 2011
122. mas pro seu azar...
Tuesday, October 18, 2011
123. suponha que seu professor queira um
algoritimo não-recursivo
Tuesday, October 18, 2011
124. suponha que seu professor queira um
algoritimo não-recursivo
#comofas
Tuesday, October 18, 2011
125. 1. você vai ter que estudar o
problema de novo
Tuesday, October 18, 2011
126. 2. você tem que alterar o
código atual de novo
Tuesday, October 18, 2011
127. 3. você vai ter que testa-lo de
novo
Tuesday, October 18, 2011
128. mas cadê minha
classe de teste?
Tuesday, October 18, 2011