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...

6. desenvolvimento de software

7. desenvolvimento de software
processo tradicional

8. desenvolvimento de software
processo tradicional
um pouquinho de XP

9. desenvolvimento de software
processo tradicional
um pouquinho de XP
Testes

10. desenvolvimento de software
processo tradicional
um pouquinho de XP
Testes
JUnit

11. O que é um
Teste?

13. você
entraria
num avião...

14. ... que nunca
saiu do
chão?
você
entraria
num avião...

15. ta
maluco?

16. e por que você
entrega software
sem testar?

17. como você desenvolve
software hoje?

18. Code and fix!

19. 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]

20. Unificação de Processos

21. • 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]

22. Inspirado em outras
engenharias
Quase sempre a civil

23. Inspirado em outras
engenharias
Quase sempre a civil

24. Inspirado em outras
engenharias
Quase sempre a civil

25. Dá pra afastar um pouquinho?

26. Custo de mudanças

28. BDUF
big design up front

29. BDUF
big design up front
is evil!

30. nós estamos jogando
com as regras
erradas!

31. “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)

33. Não é assim que se faz software

34. Não é assim que se faz software
Acredite!

35. 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.

36. XP
Extreme Programming

37. O que é XP?

38. Utilização de
funcionalidades de software
Às vezes
Frequentemente
16%
13%
Sempre
7%
Raramente
19%
Nunca
45%

39. desperdício
Raramente
19%
Nunca
45%

40. Pareto
Frequentemente
13%
Sempre
7%
20% das funcionalidades
geram 80% do valor

41. XP é a arte de maximizar a
quantidade de software que
você não vai fazer
Vinícius Manhães Teles - ImproveIt

42. Extreme Programming
É um conjunto de princípios, valores e práticas

43. Onde...

44. Onde...
... os princípios conectam
os valores às práticas

45. • 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]

46. e testes vão
me salvar?

47. testes evitarão falhas?
e testes vão
me salvar?

48. falhas existem
[1] [2]

49. 1/3
poderiam ser
evitadas
falhas existem
[1] [2]

50. 1/3
poderiam ser
evitadas
50%
falhas existem são detectadas
em produção
[1] [2]

51. 1/3
poderiam ser
evitadas
50%
falhas existem são detectadas
em produção
U$60 bi ano
custam caro!
[1] [2]

53. bug

54. bug feature

55. defeitos são caros!
quanto mais tarde
forem encontrados,
mais caros serão

56. conclusão:
é melhor encontrar os
defeitos o mais cedo
possível!

57. depois eu testo

58. estou sem tempo

59. funcionou!?

60. funcionou!?

61. seja profissional
garanta o seu trabalho!

62. você é o único
responsável pela
qualidade do seu
trabalho

63. ninguém melhora se
você não melhorar
primeiro!

64. programadores
profissionais
escrevem testes.
[3]

65. teste tudo antes - TDD

66. quando você
terminar

67. quando você
terminar
é porque você
realmente terminou

68. quando você
terminar
é porque você
realmente terminou

69. escreva os testes
antes!

70. você vai

71. você vai
amar seus códigos

72. você vai
amar seus códigos
programar melhor

73. você vai
amar seus códigos
programar melhor
pensar antes de escrever

74. você vai
amar seus códigos
programar melhor
pensar antes de escrever
reduzir código inútil

75. você vai
amar seus códigos
programar melhor
pensar antes de escrever
reduzir código inútil
ganhar com qualidade

76. “Sempre que estiver tentado a
escrever um print() ou uma
expressão de depuração, escreva um
teste”
-- Martin Fowler

77. entre no ritmo

78. stand-up meeting @ 09:00h
monte seu par
escreva um teste
codifique para passar no teste refatore
entregar
Ir para casa @ 17:00h

79. red

80. escreva um teste que não funciona
red

81. green

82. escreva código que passe no teste
green

83. refactor

84. refatore, recomece e refatore. Sempre!
refactor

85. testes de unidade

86. testes de unidade
teste todo seu código

87. testes de unidade
teste todo seu código
por partes

88. testes de unidade
teste todo seu código
por partes
isoladas

89. testes de unidade
teste todo seu código
por partes
isoladas
e independentes

90. testes de unidade

91. testes de unidade
evitam bugs

92. testes de unidade
evitam bugs
permitem fáceis alterações (coragem)

93. testes de unidade
evitam bugs
permitem fáceis alterações (coragem)
documenta

94. testes de unidade
evitam bugs
permitem fáceis alterações (coragem)
documenta
serve como métrica do projeto

95. testes de unidade
evitam bugs
permitem fáceis alterações (coragem)
documenta
serve como métrica do projeto
- testes == requisitos

96. rode os testes
todo o tempo

97. rode os testes
todo o tempo
é melhor corrigir
dois ou três probleminhas

98. rode os testes
todo o tempo
é melhor corrigir
dois ou três probleminhas
do que corrigir um problemão

99. mantenha tudo simples

100. mantenha tudo simples
deixe os ‘complexos’ por último

101. mantenha tudo simples
deixe os ‘complexos’ por último
seja criativo

102. mantenha tudo simples
deixe os ‘complexos’ por último
seja criativo
mantenha o foco

103. mantenha tudo simples
deixe os ‘complexos’ por último
seja criativo
mantenha o foco
use dados suficientes

104. mantenha tudo simples
deixe os ‘complexos’ por último
seja criativo
mantenha o foco
use dados suficientes
- se 3 condições bastam, pra que 10?

105. achou um bug?

106. não o conserte antes de ter
um teste que o reproduza
achou um bug?

107. não o conserte antes de ter
um teste que o reproduza
achou um bug?
ou então ele volta!

108. JUnit

109. 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

110. escrito originalmente por Erich
Gamma e Kent Beck
parte de uma família de
arquitetura de testes
conhecida como xUnit

111. pra que um framework?

112. pra que um framework?
verifica toda unidade de código

113. pra que um framework?
verifica toda unidade de código
facilita a criação

114. pra que um framework?
verifica toda unidade de código
facilita a criação
facilita a automatização

115. pra que um framework?
verifica toda unidade de código
facilita a criação
facilita a automatização
é OO, gratuito, Open Source ...

116. JUnit 4 ficou
muito simples

117. @Test
anote seu método
não precisa mais do prefixo test
suas classes não precisam estender
TestCase

118. @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

119. Exceptions
@Test(expected = ArithmeticException.class)
@Ignore
@Ignore(“Não pode ser executado ainda.”)
@Test

120. Timeout
@Test(timeout = 1000)

121. o ritual

122. saiba o vai implementar

123. saiba o vai implementar
liste tudo que deve ser feito

124. saiba o vai implementar
liste tudo que deve ser feito
escreva um teste antes para
qualquer tarefa listada

125. saiba o vai implementar
liste tudo que deve ser feito
escreva um teste antes para
qualquer tarefa listada
certifique-se que o teste falhe

126. implemente

127. implemente
implemente um código simples
para passar no teste

128. implemente
implemente um código simples
para passar no teste
refatore o teste e depois o
código

129. implemente
implemente um código simples
para passar no teste
refatore o teste e depois o
código
recomece

130. alguns lembretes

131. alguns lembretes
assertEquals

132. alguns lembretes
assertEquals
- testa igualdade (esperado x retornado)

133. alguns lembretes
assertEquals
- testa igualdade (esperado x retornado)
assertTrue

134. alguns lembretes
assertEquals
- testa igualdade (esperado x retornado)
assertTrue
- testa o retorno ‘true’

135. alguns lembretes
assertEquals
- testa igualdade (esperado x retornado)
assertTrue
- testa o retorno ‘true’
assertFalse

136. alguns lembretes
assertEquals
- testa igualdade (esperado x retornado)
assertTrue
- testa o retorno ‘true’
assertFalse
- testa o retorno ‘false’

137. alguns lembretes

138. alguns lembretes
assertNull

139. alguns lembretes
assertNull
- testa se um valor é nulo

140. alguns lembretes
assertNull
- testa se um valor é nulo
assertNotNull

141. alguns lembretes
assertNull
- testa se um valor é nulo
assertNotNull
- testa se um valor não é nulo

142. hands on!

143. dúvidas?

144. http://www.esjug.org

145. 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

146. Obrigado!
podem acordar

147. Testes de Unidade
com JUnit
Paulo César M. Jeveaux
paulo.jeveaux@giran.com.br