2. J ô
Jevô
• Analista Senior de WebMedia na globo.com
• Desenvolvedor Java há 7++ anos
• Administrador do PortalJava e ESJUG
• Palestrante‐Entusiasta‐Evangelista Java
Palestrante‐Entusiasta‐Evangelista Java
• Entusiasta Python, Rails e Agile
h l l
3. A d
Agenda
• Introdução
• Bug
• Você confia no que faz? Afinal é um teste?
Você confia no que faz? Afinal é um teste?
• Cobertura de testes
• Tipos de testes
• Desenvolvendo orientado a testes
• Ferramentas e técnicas de testes
F t té i d t t
• Refatoração
8. F lh d S ft
Falhas de Software
• Mais de 1/3 das falhas
poderiam ser evitadas
ser evitadas
com testes; [1]
• Cerca de 50% das falhas
de 50% das falhas
só são descobertas em
produção;
produção; [1]
10. F lh
Falhas custam $$$
t $$$
• Segundo uma pesquisa do Departamento de
Comércio dos EUA, publicada em 2002, falhas
C é i d EUA bli d 2002 f lh
de software são tão comuns e tão danosas
que se estima que causem um prejuízo anual
de mais de 60 bilhões de dólares para a
de mais de 60 bilhões de dólares para a
economia americana. [1], [2]
12. Introdução
Desenvolvimento de software
Desen ol imento de soft are
Falhas de Software
Falhas custam caro
Testes não evitam falhas
Testes identificam as falhas antes delas
Testes identificam as falhas antes delas
acontecerem
22. Bugs
Metodologias ágeis, como o XP, defendem
g g , ,
que, ao encontrarmos um problema,
que, ao encontrarmos um problema,
antes de desenvolver uma solução
antes de desenvolver uma solução
devemos criar um teste que detecte tal
devemos criar um teste que detecte tal
problema.
bl
25. G
Garanta o que você faz
t êf
• Cliente:
– Isso aqui não está funcionando!
• Programador:
– Mas como!? Na minha máquina estava
funcionando até ontem.
funcionando até ontem
27. G
Garanta o que você faz
t êf
Depois eu escrevo o
p
plano de testes…
Vamos deixar os testes
pra próxima fase…
28. G
Garanta o que você faz
t êf
Depois eu escrevo o
p
plano de testes…
Vamos deixar os testes
pra próxima fase…
Na minha
Na minha máquina está
funcionando…
29. G
Garanta o que você faz
t êf
Depois eu escrevo o
D i
plano de testes
de testes…
Vamos deixar os testes
pra próxima fase…
Precisamos entregar o
produto semana que vem!!!
Na minha máquina está
funcionando…
30. G t t b lh
Garanta o seu trabalho seja profissional
j fi i l
Errado! (como se safar) Realidade!
• Num mundo capitalizado • O cliente não quer saber se
não há tempo para testes
não há tempo para testes X virou Y. Ele quer que o
X virou Y Ele quer que o
• O cliente não quer saber
q problema não aconteça e se
como é feito, ele quer que acontecer que seja corrigido
funcione rapidamente
• Não se consegue qualidade
Não se consegue qualidade
e confiabilidade sem testes
[4]
32. O
O que são testes?
ã t t ?
Um teste é uma verificação feita sobre um
código ou fragmento de código para garantir
que uma determinada entrada produza,
sempre, uma saída esperada
33. O
O que são testes?
ã t t ?
• São pontuais
São pontuais
• São previsíveis
• São finitos
São finitos
• São (ou deveriam ser) simples
35. Whit B
White Box
• Testes de unidade de código;
g ;
• Testam parte da solução;
Testam parte da solução;
• São escritos e mantidos pelo
programador e devem estar sempre
atualizados;
37. Bl k B
Black Box
• Testes funcionais e de aceitação;
Testes funcionais e de aceitação;
• Testes de integração;
d i ã
• Testam a solução completa;
38. C b t
Cobertura dos testes
d t t
Resultado esperado
Trecho alterado
com alteração: OK
Reflexo da alteração
Erro #1
Reflexo da alteração
Erro #2
Reflexo da alteração
BUG
Reflexo da alteração
Inesperado
I d
39. C b t
Cobertura dos testes
d t t
Sem cobertura Com cobertura
• Novo release = códigos
sem testes;
• Não há segurança de
Não há segurança de
que as alterações não
irão impactar em outros
irão impactar em outros
pontos da aplicação;
• Problemas muitos
Problemas, muitos
problemas;
40. C b t
Cobertura dos testes
d t t
• Dificilmente consegue‐se 100% de cobertura
de testes, contete‐se com 99%
• Quanto maior a cobertura dos testes na
aplicação maior a confiabilidade nas
alterações e novos recursos
41. C b t
Cobertura dos testes
d t t
• Aplicações cobertas por bons testes
propiciam:
i i
– Facilidade de manutenção;
Facilidade de manutenção;
– Facilidade para inclusão de novos membros no
Facilidade para inclusão de novos membros no
;
time de desenvolvimento;
– Redução de problemas e custos nas manutenções;
ç p ç
– Telefone silencioso nas madrugadas!
42. T t ã
Testes são necessários
ái
• Você precisa verificar o código, sempre
• Você precisa garantir que os requisitos estão
p g q q
implementados (e corretos)
p ( )
• Você precisa ter segurança para realizar
Você precisa ter segurança para realizar
alterações
ç
43. T t ã
Testes são necessários
ái
• Você precisa testar rápido para entregar rápido
• Você precisa ser criativo para explorar o máximo
possível com seus testes, não use testes mentirosos
• Você aumenta e garante a qualidade da sua solução
com testes
45. T t U itá i
Testes Unitários
• Testam uma parte isolada da solução, um
componente ou trecho de código
• Todo o resto é simulado através de Mock
Objets;
• É fundamental para TDD
p
46. T t U itá i
Testes Unitários
[wikipedia]
É a fase do processo de teste em que se testam as menores
unidades de software desenvolvidas
O universo alvo desse tipo de teste são os métodos dos objetos
O universo alvo desse tipo de teste são os métodos dos objetos
ou mesmo pequenos trechos de código. Assim, o objetivo é o
de encontrar falhas de funcionamento dentro de uma
pequena parte do sistema funcionando independentemente
do todo.
[/wikipedia]
47. Testes Unitários
T t U itá i
• Ferramentas:
– JUnit/NUnit e TestNG: para testes unitários
– JMock: para criação de objetos e cenários falsos
49. T t d
Testes de aceitação
it ã
• Testam uma história, funcionalidade ou caso
de uso
• Envolvem vários componentes do sistema ou
p
até o sistema como um todo
• Ex. ferramentas: JUnit, Selenium, Fit/FitNesse
, , /
51. T t d i t
Testes de integração
ã
• Testam a integração entre componentes
• Envolvem dois ou mais componentes
p
• Ex ferramentas: JUnit DBUnit HSQLDB
Ex. ferramentas: JUnit, DBUnit, HSQLDB
• Normalmente não é muito utilizado em TDD
Normalmente não é muito utilizado em TDD
53. TDD
refatore
Escreva código
E
Escreva um
que passe
Teste no teste
54. R
Regras Fundamentais
F d t i
• Escreva o teste da implementação ANTES de
escrevê‐la
• Escreva somente código suficiente para o
g p
teste passar e nada além disso
• Escreva testes pequenos
p q
• Escreva testes muito rápidos
Escreva testes muito rápidos
[10]
56. JU it
JUnit
• É um framework altamente eficaz e
largamente utilizado na criação e execução de
l t tili d i ã ã d
g
testes unitários de códigos
http://junit.org
57. U t t
Um teste com JUnit
JU it
public class HelloWorldTest {
@ est
@Test
public void testMultiplicacao() {
//Testando se 2*2 = 4
assertEquals (“Mult”, 4, 2*2);
( Mult , 2 2);
}
}
61. U t t
Um teste com TestNG
T tNG
import org.testng.annotations.*;
public class SimpleTest {
@BeforeClass
public void setUp() {
}
@Test(groups = { quot;calculadoraquot; })
public void somaTest() {
bli id T t()
System.out.println(quot;somaquot;);
}
}
63. JM k
JMock
• Utilizado para criar ou simular falsos
objetos/cenários
• Alternativas:
– EasyMock
– MockObjetc
64. S l i
Selenium
• Ferramenta para realização de testes
integrados e de aceitação
• Usado no browser, grava todos os passos
,g p
executados na aplicação diretamente no
browser e os executa de forma automatizada
no browser
66. Cl
Clover
• Ferramenta para análise de cobertura dos
testes existem na aplicação
• Integrado a várias IDEs ‐ Eclipse ;‐)
g p ;)
• Existem diversas opções semelhantes:
Existem diversas opções semelhantes:
JCoverage, Cobertura, etc
g , ,
71. C d
Codesmell
ll
• Codesmell ou code smell é um dos conceitos
criados pelo XP
• Um code smell é uma indicação superficial de
ç p
que algo pode estar errado. Aquela mesma
sensação quando você abre sua geladeira e
sente um cheiro estranho
74. R f t
Refatoração
ã
• Sempre existiu, mas não tinha um nome
• Estava implícito
p
• A novidade foi criar um vocabulário comum e
A novidade foi criar um vocabulário comum e
catalogá los
catalogá‐los
• Assim podemos utilizar mais sistematicamente
Assim podemos utilizar mais sistematicamente
e ensinar uns aos outros
e ensinar uns aos outros
75. Q
Quando refatorar?
d f t ?
• Sempre há duas possibilidades:
– Melhorar o código existente.
– Jogar fora e começar do 0.
• É sua responsabilidade avaliar a situação e
decidir quando é a hora de optar por um ou
por outro.
76. R f t
Refatoração
ã
• Os principais objetivos são:
– Tornar o código mais claro, limpo, simples e
elegante;
– Permitir que componentes mais simples ou
expressões mais eficientes sejam usadas.
77. R f t
Refatoração: Benefícios
ã B fí i
• Redução de código duplicado
• Aumentar a simplicidade
p
• Facilitar a leitura
Facilitar a leitura
• Melhorar a performance e eficência
Melhorar a performance e eficência
• Manutenibilidade
78. R f t
Refatorar X Reescrever
XR
Refatorar Reescrever
• Não altera a • Altera a
funcionalidade ou funcionalidade do
conteúdo do sistema/solução
sistema/solução
i t / l ã
80. G
Garanta‐se nos testes
t t t
• Antes de começar a refatorar verifique se você
tem um conjunto de testes para garantir a
funcionalidade do código a ser refatorado
• Refatorações podem adicionar erros
• Os testes vão ajudá‐lo a detectar erros se eles
j
forem criados
81. Conclusões
C l õ
• Testes colaboram para o aumento da
qualidade d
lid d dos sistemas;
it
• Desenvolvedores ficam mais corajosos e
Desenvolvedores ficam mais corajosos e
confiantes ao programar;
• O software cresce de forma ordenada e com
qualidade de design;
de design;
• O software se adapta com mais facilidade a
mudanças;
82. Conclusões
C l õ
• Demora mais?
– No início é necessário escrever muitos testes;;
– Depois da inércia a suite de testes está pronta e escrevem‐
se menos testes;
– Certeza de que a implementação está funcionando;
– Maioria dos bugs encontrados em tempo de
d
desenvolvimento;
l i t
– Bugs de produção são encontrados e corrigidos com muito
mais velocidade;
mais velocidade;
• Então no fim das contas demora‐se muito menos
tempo e com muito mais qualidade;
tempo e com muito mais qualidade;
[10]
84. Referências
R f ê i
• [1] ‐ NIST ‐ http://www.nist.gov/public_affairs/releases/n02‐10.htm
• [2] ‐ ImproveIt ‐ http://www.improveit.com.br/xp/praticas/tdd
• [ ] p // g
[3] ‐ Caelum ‐ http://blog.caelum.com.br/2006/09/08/voce‐acredita‐no‐seu‐codigo/
/ / / / g /
• [4] – Fragmental ‐ Shoes ‐ http://blog.fragmental.com.br/2007/10/31/programadores‐
profissionais‐escrevem‐testes‐ponto‐final/
• [5] – Marcos Pereira – http://marcospereira.wordpress.com/2007/11/27/desenvolvedores‐
odeiam‐testar
d i t t
• [6] – Wikipedia – http://en.wikipedia.org/wiki/Test‐driven_development
• [7] ‐ TDD ‐ http://www.testdriven.com
• [8] Brod http://www brod com br
[8] ‐ Brod ‐ http://www.brod.com.br
• [9] – java.net ‐ http://wiki.java.net/bin/view/People/SmellsToRefactorings
• [10] – Palestra Desenvolvimento Guiado por Testes (TDD) – Guilherme Chapiewski
• Algumas ilustações foram retiradas do site da ImproveIt.
85. refatore
Escreva código
Escreva um
E
que passe
Teste no teste
86. D íd C íti
Duvídas, Críticas e Sugestões
S tõ
• Para contato:
– www.jeveaux.com
– www.portaljava.com
t lj
– paulo@jeveaux.com
– jeveaux@portaljava.com
Obrigado a todos!
Obrigado a todos!
27/09/2008