Testes de Unidadecom JUnit

Paulo César M. Jeveaux

paulo.jeveaux@giran.com.br

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

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

Sobre o que vamos falar hoje...

desenvolvimento de software

desenvolvimento de software

processo tradicional

desenvolvimento de software

processo tradicional

um pouquinho de XP

desenvolvimento de software

processo tradicional

Testes

um pouquinho de XP

desenvolvimento de software

processo tradicional

Testes

um pouquinho de XP

JUnit

O que é umTeste?

você entrarianum avião...

você entrarianum avião...

... que nuncasaiu do

chão?

ta maluco?

e por que vocêentrega softwaresem testar?

como você desenvolvesoftware hoje?

Code and fix!

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

O processo tradicional

Unificação de Processos

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

Quase sempre a civil

Inspirado em outrasengenharias

Quase sempre a civil

Inspirado em outrasengenharias

Quase sempre a civil

Inspirado em outrasengenharias

Dá pra afastar um pouquinho?

Custo de mudanças

BDUFbig design up front

BDUFbig design up front

is evil!

nós estamos jogando

com as regras erradas!

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

Não é assim que se faz software

Não é assim que se faz software

Acredite!

Manifesto ÁgilEstamos 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 ferramentasSoftware em funcionamento mais que documentação abrangente

Colaboração com o cliente mais que negociação de contratosResponder 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, JamesGrenning, 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.

XPExtreme Programming

O que é XP?

Sempre7%

Frequentemente13%

Às vezes16%

Raramente19%

Nunca45%

Utilização de funcionalidades de software

Raramente19%

Nunca45%

desperdício

Sempre7%

Frequentemente13%

Pareto

20% das funcionalidadesgeram 80% do valor

XP é a arte de maximizar a quantidade de software que

você não vai fazerVinícius Manhães Teles - ImproveIt

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

Onde...

Onde...

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

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

e testes vão me salvar?

e testes vão me salvar?

testes evitarão falhas?

falhas existem

[1] [2]

falhas existem

1/3poderiam ser

evitadas

[1] [2]

falhas existem

1/3poderiam ser

evitadas

50%são detectadasem produção

[1] [2]

falhas existem

1/3poderiam ser

evitadas

50%são detectadasem produção

U$60 bi anocustam caro!

[1] [2]

bug

bug feature

defeitos são caros!

quanto mais tarde forem encontrados, mais caros serão

conclusão:é melhor encontrar os defeitos o mais cedo

possível!

depois eu testo

estou sem tempo

funcionou!?

funcionou!?

seja profissionalgaranta o seu trabalho!

você é o únicoresponsável pelaqualidade do seu

trabalho

ninguém melhora sevocê não melhorarprimeiro!

programadoresprofissionais

escrevem testes.[3]

teste tudo antes - TDD

quando você terminar

quando você terminar

é porque vocêrealmente terminou

quando você terminar

é porque vocêrealmente terminou

escreva os testesantes!

você vai

você vai

amar seus códigos

você vai

amar seus códigos

programar melhor

você vai

amar seus códigos

programar melhor

pensar antes de escrever

você vai

amar seus códigos

programar melhor

pensar antes de escrever

reduzir código inútil

você vai

amar seus códigos

programar melhor

pensar antes de escrever

reduzir código inútil

ganhar com qualidade

“Sempre que estiver tentado a escrever um print() ou uma

expressão de depuração, escreva um teste”

-- Martin Fowler

entre no ritmo

stand-up meeting @ 09:00h

monte seu par

escreva um teste

codifique para passar no teste refatore

entregar

Ir para casa @ 17:00h

red

red

escreva um teste que não funciona

green

green

escreva código que passe no teste

refactor

refactor

refatore, recomece e refatore. Sempre!

testes de unidade

testes de unidadeteste todo seu código

testes de unidadeteste todo seu código

por partes

testes de unidadeteste todo seu código

por partes

isoladas

testes de unidadeteste todo seu código

por partes

isoladas

e independentes

testes de unidade

testes de unidadeevitam bugs

testes de unidadeevitam bugs

permitem fáceis alterações (coragem)

testes de unidadeevitam bugs

permitem fáceis alterações (coragem)

documenta

testes de unidadeevitam bugs

permitem fáceis alterações (coragem)

documenta

serve como métrica do projeto

testes de unidadeevitam bugs

permitem fáceis alterações (coragem)

documenta

serve como métrica do projeto

- testes == requisitos

rode os testes todo o tempo

rode os testes todo o tempo

é melhor corrigirdois ou três probleminhas

rode os testes todo o tempo

é melhor corrigirdois ou três probleminhas

do que corrigir um problemão

mantenha tudo simples

mantenha tudo simplesdeixe os ‘complexos’ por último

mantenha tudo simplesdeixe os ‘complexos’ por último

seja criativo

mantenha tudo simplesdeixe os ‘complexos’ por último

seja criativo

mantenha o foco

mantenha tudo simplesdeixe os ‘complexos’ por último

seja criativo

mantenha o foco

use dados suficientes

mantenha tudo simplesdeixe os ‘complexos’ por último

seja criativo

mantenha o foco

use dados suficientes

- se 3 condições bastam, pra que 10?

achou um bug?

achou um bug?

não o conserte antes de terum teste que o reproduza

achou um bug?

não o conserte antes de terum teste que o reproduza

ou então ele volta!

JUnit

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

escrito originalmente por Erich Gamma e Kent Beck

parte de uma família de arquitetura de testes

conhecida como xUnit

pra que um framework?

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

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

facilita a criação

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

facilita a criação

facilita a automatização

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

facilita a criação

facilita a automatização

é OO, gratuito, Open Source ...

JUnit 4 ficou muito simples

@Test

anote seu métodonão precisa mais do prefixo test

suas classes não precisam estenderTestCase

@Before e @After

anote seus métodos que serão osetUp e tearDown

@BeforeClass e @AfterClass

anote seus métodos que serão osetUp e tearDown em nível de classe

Exceptions

@Test(expected = ArithmeticException.class)

@Ignore

@Ignore(“Não pode ser executado ainda.”)@Test

Timeout

@Test(timeout = 1000)

o ritual

saiba o vai implementar

saiba o vai implementarliste tudo que deve ser feito

saiba o vai implementarliste tudo que deve ser feito

escreva um teste antes paraqualquer tarefa listada

saiba o vai implementarliste tudo que deve ser feito

escreva um teste antes paraqualquer tarefa listada

certifique-se que o teste falhe

implemente

implementeimplemente um código simplespara passar no teste

implementeimplemente um código simplespara passar no teste

refatore o teste e depois o código

implementeimplemente um código simplespara passar no teste

refatore o teste e depois o código

recomece

alguns lembretes

alguns lembretesassertEquals

alguns lembretesassertEquals

- testa igualdade (esperado x retornado)

alguns lembretesassertEquals

- testa igualdade (esperado x retornado)

assertTrue

alguns lembretesassertEquals

- testa igualdade (esperado x retornado)

assertTrue- testa o retorno ‘true’

alguns lembretesassertEquals

- testa igualdade (esperado x retornado)

assertTrue- testa o retorno ‘true’

assertFalse

alguns lembretesassertEquals

- testa igualdade (esperado x retornado)

assertTrue- testa o retorno ‘true’

assertFalse- testa o retorno ‘false’

alguns lembretes

alguns lembretesassertNull

alguns lembretesassertNull

- testa se um valor é nulo

alguns lembretesassertNull

- testa se um valor é nulo

assertNotNull

alguns lembretesassertNull

- testa se um valor é nulo

assertNotNull- testa se um valor não é nulo

hands on!

dúvidas?

http://www.esjug.org

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

Obrigado!podem acordar

Testes de Unidadecom JUnit

Paulo César M. Jeveaux

paulo.jeveaux@giran.com.br