SlideShare uma empresa Scribd logo
Java 2 Standard Edition

Testes de Unidade
com JUnit
Helder da Rocha (helder@acm.org)

argonavis.com.br
1
Sobre este módulo
Este módulo é mais sobre boas práticas de
desenvolvimento e menos sobre Java

Abordagem será superficial (material é extenso), mas visa
despertar seu interesse no hábito de escrever testes.

Objetivos

Apresentar e incentivar a prática de testes de unidade
durante o desenvolvimento
Apresentar a ferramenta JUnit, que ajuda na criação e
execução de testes de unidade em Java
Discutir as dificuldades relativas à "arte" de testar e como
podem ser superadas ou reduzidas
Torná-lo(a) uma pessoa "viciada" em testes: Convencêlo(a) a nunca escrever uma linha sequer de código sem
antes escrever um teste executável que a justifique.

2
O que é "Testar código"?
É a coisa mais importante do desenvolvimento
Se seu código não funciona, ele não presta!

Todos testam
Você testa um objeto quando escreve uma classe e cria
algumas instâncias no método main()
Seu cliente testa seu software quando ele o utiliza (ele
espera que você o tenha testado antes)

O que são testes automáticos?
São programas que avaliam se outro programa funciona
como esperado e retornam resposta tipo "sim" ou "não"
Ex: um main() que cria um objeto de uma classe testada,
chama seus métodos e avalia os resultados
Validam os requisitos de um sistema

3
Por que testar?
Por que não?
Como saber se o recurso funciona sem testar?
Como saber se ainda funciona após refatoramento?

Testes dão maior segurança: coragem para mudar
Que adianta a OO isolar a interface da implementação se
programador tem medo de mudar a implementação?
Código testado é mais confiável
Código testado pode ser alterado sem medo

Como saber quando o projeto está pronto
Testes == requisitos 'executáveis'
Testes de unidade devem ser executados o tempo todo
Escreva os testes antes. Quando todos rodarem 100%, o
projeto está concluído!

4
O que é JUnit?
Um framework que facilita o desenvolvimento e
execução de testes de unidade em código Java
Uma API para construir os testes
Aplicações para executar testes

A API
Classes Test, TestCase, TestSuite, etc. oferecem a
infraestrutura necessária para criar os testes
Métodos assertTrue(), assertEquals(), fail(), etc. são
usados para testar os resultados

Aplicação TestRunner
Roda testes individuais e suites de testes
Versões texto, Swing e AWT
Apresenta diagnóstico sucesso/falha e detalhes

5
Para que serve?
'Padrão' para testes de unidade em Java
Desenvolvido por Kent Beck (XP) e Erich Gamma (GoF)
Design muito simples

Testar é uma boa prática, mas é chato; JUnit torna
as coisas mais agradáveis, facilitando
A criação e execução automática de testes
A apresentação dos resultados

JUnit pode verificar se cada unidade de código
funciona da forma esperada
Permite agrupar e rodar vários testes ao mesmo tempo
Na falha, mostra a causa em cada teste

Serve de base para extensões
6
Arquitetura do JUnit
Diagrama de classes

Fonte: Manual do JUnit (Cooks Tour)

7
Como usar o JUnit?
Há várias formas de usar o JUnit. Depende da
metodologia de testes que está sendo usada
Código existente: precisa-se escrever testes para classes
que já foram implementadas
Desenvolvimento guiado por testes (TDD): código novo
só é escrito se houver um teste sem funcionar

Onde obter?
www.junit.org

Como instalar?
Incluir o arquivo junit.jar no classpath para compilar e
rodar os programas de teste

Para este curso
Inclua o junit.jar no diretório lib/ de seus projetos

8
JUnit para testar código existente
Exemplo de um roteiro típico
1. Crie uma classe que estenda junit.framework.TestCase
para cada classe a ser testada
import junit.framework.*;
class SuaClasseTest extends TestCase {...}

2. Para cada método xxx(args) a ser testado defina um
método public void testXxx() no test case
SuaClasse:
public boolean equals(Object o) { ... }

SuaClasseTest:
public void testEquals() {...}

Sobreponha o método setUp(), se necessário
Sobreponha o método tearDown(), se necessário

9
JUnit para guiar o desenvolvimento
Cenário de Test-Driven Development (TDD)
1. Defina uma lista de tarefas a implementar
2. Escreva uma classe (test case) e implemente um
método de teste para uma tarefa da lista.
3. Rode o JUnit e certifique-se que o teste falha
4. Implemente o código mais simples que rode o teste
Crie classes, métodos, etc. para que código compile
Código pode ser código feio, óbvio, mas deve rodar!

5. Refatore o código para remover a duplicação de
dados
6. Escreva mais um teste ou refine o teste existente
7. Repita os passos 2 a 6 até implementar toda a lista

10
Como implementar?
Dentro de cada teste, utilize os métodos herdados da
classe TestCase
assertEquals(objetoEsperado, objetoRecebido),
assertTrue(valorBooleano), assertNotNull(objeto)
assertSame(objetoUm, objetoDois), fail (), ...

Exemplo de test case com um setUp() e um teste:
public class CoisaTest extends TestCase {
// construtor padrão omitido
private Coisa coisa;
public void setUp() { coisa = new Coisa("Bit"); }
public void testToString() {
assertEquals("<coisa>Bit</coisa>",
coisa.toString());
}
}

11
Como funciona?
O TestRunner recebe uma subclasse
de junit.framework.TestCase
Usa reflection (Cap 14) para achar métodos

TestCase
setUp()
tearDown()

Para cada método testXXX(), executa:
1. o método setUp()
2. o próprio método testXXX()
3. o método tearDown()

O test case é instanciado para executar
um método testXXX() de cada vez.

MeuTestCase
setUp()
testXXX()
testYYY()
tearDown()

As alterações que ele fizer ao estado do objeto não
afetarão os demais testes

Método pode terminar, falhar ou provocar exceção
12
Exemplo: um test case
package junitdemo;
import junit.framework.*;
import java.io.IOException;

Construtor precisa ser
publico, receber String
name e chamar
super(String name)

public class TextUtilsTest extends TestCase {
public TextUtilsTest(String name) {
super(name);
}

(JUnit 3.7 ou anterior)

Método começa com "test"
e é sempre public void

public void testRemoveWhiteSpaces() throws IOException {
String testString = "one, ( two | three+) ,
"+
"(((four+ |t five)?n n, six?";
String expectedString = "one,(two|three+)"+
",(((four+|five)?,six?";
String results = TextUtils.removeWhiteSpaces(testString);
assertEquals(expectedString, results);
}
}

13
Exemplo: uma classe que faz o teste passar
package junitdemo;
import java.io.*;
public class TextUtils {
public static String removeWhiteSpaces(String text)
throws IOException {
return "one,(two|three+),(((four+|five)?,six?";
}
}

O teste passa... e daí? A solução está pronta? Não!
Tem dados duplicados! Remova-os!
Escreva um novo teste que faça com que esta solução
falhe, por exemplo:
String test2 = " a
bnc
";
assertEquals("abc", TextUtils.removeWhiteSpaces(test2));

14
Outra classe que faz o teste passar
package junitdemo;
import java.io.*;
public class TextUtils {
public static String removeWhiteSpaces(String text)
throws IOException {
StringReader reader = new StringReader(text);
StringBuffer buffer = new StringBuffer(text.length());
int c;
while( (c = reader.read()) != -1) {
if (c ==' '||c =='n'||c =='r'|| c =='f'||c =='t') {
; /* do nothing */
} else {
buffer.append((char)c);
}
}
return buffer.toString();
}
}

15
Exemplo: como executar
Use a interface de texto
java -cp junit.jar junit.textui.TestRunner
junitdemo.TextUtilsTest

Ou use a interface gráfica
java -cp junit.jar junit.swingui.TestRunner
junitdemo.TextUtilsTest

Use Ant <junit>
tarefa do Apache Ant

Ou forneça um main():
public static void main (String[] args) {
TestSuite suite =
new TestSuite(TextUtilsTest.class);
junit.textui.TestRunner.run(suite);
}

16
TestSuite
Permite executar uma coleção de testes
Método addTest(TestSuite) adiciona um teste na lista

Padrão de codificação (usando reflection):
retornar um TestSuite em cada test-case:
public static TestSuite suite() {
return new TestSuite(SuaClasseTest.class);
}

criar uma classe AllTests que combina as suites:
public class AllTests {
public static Test suite() {
TestSuite testSuite =
Pode incluir
new TestSuite("Roda tudo");
outras suites
testSuite.addTest(pacote.AllTests.suite());
testSuite.addTest(MinhaClasseTest.suite());
testSuite.addTest(SuaClasseTest.suite());
return testSuite;
}
17
}
Fixtures
São os dados reutilizados por vários testes
public class AttributeEnumerationTest extends TestCase {
String
testString;
String[] testArray;
Fixture
AttributeEnumeration testEnum;
public void setUp() {
testString = "(alpha|beta|gamma)";
testArray = new String[]{"alpha", "beta", "gamma"};
testEnum = new AttributeEnumeration(testArray);
}
public void testGetNames() {
assertEquals(testEnum.getNames(), testArray);
}
public void testToString() {
assertEquals(testEnum.toString(), testString);
}
(...)

Se os mesmos dados são usados em vários testes, inicialize-os no
setUp() e faça a faxina no tearDown() (se necessário)
Não perca tempo pensando nisto antes. Escreva seus testes.
Depois, se achar que há duplicação, monte o fixture.
18
Teste situações de falha
É tão importante testar o cenário de falha do seu
codigo quanto o sucesso
Método fail() provoca uma falha
Use para verificar se exceções ocorrem quando se espera
que elas ocorram

Exemplo
public void testEntityNotFoundException() {
resetEntityTable(); // no entities to resolve!
try {
// Following method call must cause exception!
ParameterEntityTag tag = parser.resolveEntity("bogus");
fail("Should have caused EntityNotFoundException!");
} catch (EntityNotFoundException e) {
// success: exception occurred as expected
}
}

19
JUnit vs. asserções
Afirmações do J2SDK 1.4 são usadas dentro do código
Podem incluir testes dentro da lógica procedural de um programa
if (i%3 == 0) {
doThis();
} else if (i%3 == 1) {
doThat();
} else {
assert i%3 == 2: "Erro interno!";
}

Provocam um AssertionError quando falham (que pode ser
encapsulado pelas exceções do JUnit)

Afirmações do JUnit são usadas em classe separada (TestCase)
Não têm acesso ao interior dos métodos (verificam se a interface
dos métodos funciona como esperado)

Afirmações do J2SDK1.4 e JUnit são complementares
JUnit testa a interface dos métodos
assert testa trechos de lógica dentro dos métodos
20
Limitações do JUnit
Acesso aos dados de métodos sob teste
Métodos private e variáveis locais não podem ser
testadas com JUnit.
Dados devem ser pelo menos package-private (friendly)

Soluções com refatoramento
Isolar em métodos private apenas código inquebrável
Transformar métodos private em package-private
Desvantagem: quebra ou redução do encapsulamento
Classes de teste devem estar no mesmo pacote que as classes
testadas para ter acesso

Solução usando extensão do JUnit (open-source)
JUnitX: usa reflection para ter acesso a dados private
http://www.extreme-java.de/junitx/index.html
21
Resumo: JUnit
Para o JUnit,
Um teste é um método
Um caso de teste é uma classe contendo uma coleção de testes
(métodos que possuem assertions)
Cada teste testa o comportamento de uma unidade de código do
objeto testado (pode ser um método, mas pode haver vários testes
para o mesmo método ou um teste para todo o objeto)

Fixtures são os dados usados em testes
TestSuite é uma composição de casos de teste
Pode-se agrupar vários casos de teste em uma suite

JUnit testa apenas a interface das classes
Mantenha os casos de teste no mesmo diretório que as classes
testadas para ter acesso a métodos package-private
Use padrões de nomenclatura: ClasseTest, AllTests
Use o Ant para separar as classes em um release

22
Apêndice: boas práticas
e dificuldades com testes

23
Como escrever bons testes
JUnit facilita bastante a criação e execução de
testes, mas elaborar bons testes exige mais
O que testar? Como saber se testes estão completos?

"Teste tudo o que pode falhar" [2]
Métodos triviais (get/set) não precisam ser testados.
E se houver uma rotina de validação no método set?

É melhor ter testes a mais que testes a menos
Escreva testes curtos (quebre testes maiores)
Use assertNotNull() (reduz drasticamente erros de
NullPointerException difíceis de encontrar)
Reescreva seu código para que fique mais fácil de testar
24
Como descobrir testes?
Escreva listas de tarefas (to-do list)
Comece pelas mais simples e deixe os testes "realistas"
para o final
Requerimentos, use-cases, diagramas UML: rescreva os
requerimentos em termos de testes

Dados
Use apenas dados suficientes (não teste 10 condições se
três forem suficientes)

Bugs revelam testes
Achou um bug? Não conserte sem antes escrever um
teste que o pegue (se você não o fizer, ele volta)!

Teste sempre! Não escreva uma linha de código sem
antes escrever um teste!

25
Test-Driven Development (TDD)
Desenvolvimento guiado pelos testes
Só escreva código novo se um teste falhar
Refatore até que o teste funcione
Alternância: "red/green/refactor" - nunca passe mais de
10 minutos sem que a barra do JUnit fique verde.

Técnicas
"Fake It Til You Make It": faça um teste rodar
simplesmente fazendo método retornar constante
Triangulação: abstraia o código apenas quando houver
dois ou mais testes que esperam respostas diferentes
Implementação óbvia: se operações são simples,
implemente-as e faça que os testes rodem
26
Como lidar com testes difíceis
Testes devem ser simples e suficientes

XP: design mais simples que resolva o problema;
sempre pode-se escrever novos testes, quando necessário

Não complique

Não teste o que é responsabilidade de outra classe/método
Assuma que outras classes e métodos funcionam

Testes difíceis (ou que parecem difíceis)

Aplicações gráficas: eventos, layouts, threads
Objetos inaccessíveis, métodos privativos, Singletons
Objetos que dependem de outros objetos
Objetos cujo estado varia devido a fatores imprevisíveis

Soluções
Alterar o design da aplicação para facilitar os testes
Simular dependências usando proxies e stubs
27
Dependência de código-fonte
Problema
Como testar componente que depende do código de
outros componentes?
Tanque
Classe-alvo não oferece o que testar:
+nivel()

CarroTest

Carro

+testAcelera()

+acelera()

Ignição
+ligada()

Método acelera() só vai funcionar
se nível() do tanque for > 0 public void testAcelera() {
e ignição estiver ligada()
Carro carro =
new Carro();
Como saber se condições são
carro.acelera();
verdadeiras se não temos
assert???(???);
}
acesso às dependências?
Fonte: www.objectmentor.com, 2002

28
Stubs: objetos "impostores"
É possível remover dependências de código-fonte
refatorando o código para usar interfaces
depois

antes
A

B

«interface»
InterB

A

A não conhece mais
o tipo concreto de B

B

Agora B pode ser substituída por um stub

BStub está sob controle total de ATest (1)
Em alguns casos, ATest pode implementar InterB (2)

ATest

A

«interface»
InterB

A

«interface»
InterB

(2)

(1)

« cria »

ATest

BStub

Fonte: www.objectmentor.com, 2002

B

self-shunt pattern

B

29
Dependência: solução usando stubs
«interface»
Tanque
+nivel():float

"Mock implementation" das
dependências simula os efeitos que
terão sobre Carro
CarroTest
+testTanqueVazioSemIgn()
+testTanqueCheioSemIgn()
+testTanqueVazioComIgn()
+testTanqueCheioComIgn()

TanqueImpl
+nivel():float

Carro
+acelera()
«interface»
Ignicao
+ligada(): bool

IgnicaoImpl
+ligada():bool

Quando criar o objeto, passe a implementação falsa
carro.setTanque(new CarroTest());
carro.setIgnicao(new CarroTest());

Depois preencha-a com dados suficientes para que objeto
possa ser testado
Fonte: www.objectmentor.com, 2002

30
Dependências de servidores
Usar stubs para simular serviços e dados
É preciso implementar classes que devolvam as respostas
esperadas para diversas situações
Complexidade muito grande da dependência pode não
compensar investimento (não deixe de fazer testes por
causa disto!)
Vários tipos de stubs: mock objects, self-shunts.

Usar proxies (mediadores) para serviços reais
Oferecem interface para simular comunicação e testa a
integração real do componente com seu ambiente
Não é teste unitário: teste pode falhar quando código está
correto (se os fatores externos falharem)
Exemplo em J2EE: Jakarta Cactus
31
Mock Objects
Mock objects (MO) é uma estratégia de uso de stubs
que não implementa nenhuma lógica
Um mock object não é exatamente um stub, pois não
simula o funcionamento do objeto em qualquer situação

Comportamento é controlado pela classe de teste que
Define comportamento esperado (valores retornados, etc.)
Passa MO configurado para objeto a ser testado
Chama métodos do objeto (que usam o MO)

Implementações open-source que facilitam uso de MOs
EasyMock (tammofreese.de/easymock/) e MockMaker
(www.xpdeveloper.com) geram MOs a partir de interfaces
Projeto MO (mockobjects.sourceforge.net) coleção de mock
objects e utilitários para usá-los

32
Ant + JUnit
Com Ant, pode-se executar todos os testes após a
integração com um único comando:
ant roda-testes

Com as tarefas <junit> e <junitreport> é possível
executar todos os testes
gerar um relatório simples ou detalhado, em diversos
formatos (XML, HTML, etc.)
executar testes de integração

São tarefas opcionais. É preciso ter em $ANT_HOME/lib
optional.jar (distribuído com Ant)
junit.jar
(distribuído com JUnit)
33
Exemplo: <junit>
<target name="test" depends="build">
<junit printsummary="true" dir="${build.dir}"
fork="true">
<formatter type="plain" usefile="false" />
<classpath path="${build.dir}" /
<test name="argonavis.dtd.AllTests" />
</junit>
Formata os dados na tela (plain)
</target>
Roda apenas arquivo AllTests
<target name="batchtest" depends="build" >
<junit dir="${build.dir}" fork="true">
<formatter type="xml" usefile="true" />
<classpath path="${build.dir}" />
<batchtest todir="${test.report.dir}">
<fileset dir="${src.dir}">
<include name="**/*Test.java" />
<exclude name="**/AllTests.java" />
</fileset>
</batchtest>
Gera arquivo XML
</junit>
Inclui todos os arquivos que
</target>
terminam em TEST.java

34
<junitreport>
Gera um relatório detalhado (estilo JavaDoc) de todos
os testes, sucessos, falhas, exceções, tempo, ...
<target name="test-report" depends="batchtest" >
<junitreport todir="${test.report.dir}">
<fileset dir="${test.report.dir}">
Usa arquivos XML
<include name="TEST-*.xml" />
gerados por
</fileset>
<formatter>
<report todir="${test.report.dir}/html"
format="frames" />
</junitreport>
</target>

35
Resumo
Testar é tarefa essencial do desenvolvimento de software.
Testar unidades de código durante o desenvolvimento é uma
prática que traz inúmeros benefícios
Menos tempo de depuração (muito, muito menos!)
Melhor qualidade do software
Segurança para alterar o código
Usando TDD, melhores estimativas de prazo

JUnit é uma ferramenta open-source que ajuda a
implementar testes em projetos Java
TDD ou Test-Driven Development é uma técnica onde os
testes são usados para guiar o desenvolvimento
Ajuda a focar o desenvolvimento em seus objetivos

Mock objects ou stubs podem ser usados para representar
dependência e diminuir as responsabilidades de testes
36
Exercício
1. A classe Exercicio.java possui quatro métodos vazios:
int soma(int a, int b)
long fatorial(long n);
double fahrToCelsius(double fahrenheit);
String inverte(String texto);

Escreva, na classe ExercicioTest.java, test-cases para cada
método, que preencham os requisitos:
Soma: 1+1 = 2, 2+4 = 4
Fatorial: 0! = 1, 1! = 1, 2! = 2, 3! = 6, 4! = 24, 5! = 120
A fórmula é n! = n(n-1)(n-2)(n-3)...3*2*1
Celsius: -40C = -40F, 0C=32F, 100C=212F
A fórmula é F = 9/5 * C + 32
Inverte recebe "Uma frase" e retorna "esarf amU"

Implemente um teste e execute-o (o esqueleto de um deles
já está pronto). Ele deve falhar.
Implemente os métodos, um de cada vez, e rode os testes
até que não falhem mais (tarja verde), antes de prosseguir.

37
Curso J100: Java 2 Standard Edition
Revisão 17.0

© 1996-2003, Helder da Rocha
(helder@acm.org)

argonavis.com.br
38

Mais conteúdo relacionado

Mais procurados

VACINA ANTI-RÁBICA HUMANA
 VACINA ANTI-RÁBICA HUMANA VACINA ANTI-RÁBICA HUMANA
VACINA ANTI-RÁBICA HUMANA
Sandra Tomaz
 
conteúdos UFCD 0771.ppt
conteúdos UFCD 0771.pptconteúdos UFCD 0771.ppt
conteúdos UFCD 0771.ppt
olivervis
 
powerpoint template for testing training
powerpoint template for testing trainingpowerpoint template for testing training
powerpoint template for testing training
John Roddy
 
프로젝트에서 Sw아키텍트의 역할 20140717
프로젝트에서 Sw아키텍트의 역할 20140717프로젝트에서 Sw아키텍트의 역할 20140717
프로젝트에서 Sw아키텍트의 역할 20140717
Young On Kim
 
Android Aula 1
Android Aula 1Android Aula 1
Android Aula 1
Erisvaldo Junior
 
Placa fax - modem slide
Placa   fax - modem slidePlaca   fax - modem slide
Placa fax - modem slide
Bruna Ribeiro Vieira
 
Münazara eğitmenleri için eğitim
Münazara eğitmenleri için eğitimMünazara eğitmenleri için eğitim
Münazara eğitmenleri için eğitimErdem Demirbas
 
Servidor web
Servidor webServidor web
Servidor web
Raphaela Rocha
 
Test planning
Test planningTest planning
Test planning
rahulcentra
 
Modelo documentacao-rede
Modelo documentacao-redeModelo documentacao-rede
Modelo documentacao-rede
Rod Deville
 
Aula 5 - Redes de computadores
Aula 5 - Redes de computadoresAula 5 - Redes de computadores
Aula 5 - Redes de computadores
LucasMansueto
 
Guia da Gestão de Projectos Web
Guia da Gestão de Projectos WebGuia da Gestão de Projectos Web
Guia da Gestão de Projectos Web
Arlindo Santos
 
Software testing
Software testingSoftware testing
Software testing
Simran Kaur
 
Computação em Nuvem
Computação em NuvemComputação em Nuvem
Computação em Nuvem
Rafael Barbolo
 
Linux
LinuxLinux
Les cinq bonnes pratiques des Tests Unitaires dans un projet Agile
Les cinq bonnes pratiques des Tests Unitaires dans un projet AgileLes cinq bonnes pratiques des Tests Unitaires dans un projet Agile
Les cinq bonnes pratiques des Tests Unitaires dans un projet Agile
Denis Voituron
 
CMDBuild Ready2Use紹介資料
CMDBuild Ready2Use紹介資料CMDBuild Ready2Use紹介資料
CMDBuild Ready2Use紹介資料
OSSラボ株式会社
 
Conceitos associado às redes
Conceitos associado às redesConceitos associado às redes
Conceitos associado às redes
Agrupamento de Escolas da Batalha
 
Apresentacao Veeam Backup & Replication
Apresentacao Veeam Backup & ReplicationApresentacao Veeam Backup & Replication
Apresentacao Veeam Backup & Replication
Blue Solutions
 
Aula 10 - Exclusão Mútua e Região Crítica
Aula 10 - Exclusão Mútua e Região CríticaAula 10 - Exclusão Mútua e Região Crítica
Aula 10 - Exclusão Mútua e Região Crítica
camila_seixas
 

Mais procurados (20)

VACINA ANTI-RÁBICA HUMANA
 VACINA ANTI-RÁBICA HUMANA VACINA ANTI-RÁBICA HUMANA
VACINA ANTI-RÁBICA HUMANA
 
conteúdos UFCD 0771.ppt
conteúdos UFCD 0771.pptconteúdos UFCD 0771.ppt
conteúdos UFCD 0771.ppt
 
powerpoint template for testing training
powerpoint template for testing trainingpowerpoint template for testing training
powerpoint template for testing training
 
프로젝트에서 Sw아키텍트의 역할 20140717
프로젝트에서 Sw아키텍트의 역할 20140717프로젝트에서 Sw아키텍트의 역할 20140717
프로젝트에서 Sw아키텍트의 역할 20140717
 
Android Aula 1
Android Aula 1Android Aula 1
Android Aula 1
 
Placa fax - modem slide
Placa   fax - modem slidePlaca   fax - modem slide
Placa fax - modem slide
 
Münazara eğitmenleri için eğitim
Münazara eğitmenleri için eğitimMünazara eğitmenleri için eğitim
Münazara eğitmenleri için eğitim
 
Servidor web
Servidor webServidor web
Servidor web
 
Test planning
Test planningTest planning
Test planning
 
Modelo documentacao-rede
Modelo documentacao-redeModelo documentacao-rede
Modelo documentacao-rede
 
Aula 5 - Redes de computadores
Aula 5 - Redes de computadoresAula 5 - Redes de computadores
Aula 5 - Redes de computadores
 
Guia da Gestão de Projectos Web
Guia da Gestão de Projectos WebGuia da Gestão de Projectos Web
Guia da Gestão de Projectos Web
 
Software testing
Software testingSoftware testing
Software testing
 
Computação em Nuvem
Computação em NuvemComputação em Nuvem
Computação em Nuvem
 
Linux
LinuxLinux
Linux
 
Les cinq bonnes pratiques des Tests Unitaires dans un projet Agile
Les cinq bonnes pratiques des Tests Unitaires dans un projet AgileLes cinq bonnes pratiques des Tests Unitaires dans un projet Agile
Les cinq bonnes pratiques des Tests Unitaires dans un projet Agile
 
CMDBuild Ready2Use紹介資料
CMDBuild Ready2Use紹介資料CMDBuild Ready2Use紹介資料
CMDBuild Ready2Use紹介資料
 
Conceitos associado às redes
Conceitos associado às redesConceitos associado às redes
Conceitos associado às redes
 
Apresentacao Veeam Backup & Replication
Apresentacao Veeam Backup & ReplicationApresentacao Veeam Backup & Replication
Apresentacao Veeam Backup & Replication
 
Aula 10 - Exclusão Mútua e Região Crítica
Aula 10 - Exclusão Mútua e Região CríticaAula 10 - Exclusão Mútua e Região Crítica
Aula 10 - Exclusão Mútua e Região Crítica
 

Semelhante a Testes de Unidade com JUnit

JUnit
JUnitJUnit
Testes com JUnit
Testes com JUnitTestes com JUnit
Testes com JUnit
elliando dias
 
Junit 4.0
Junit 4.0Junit 4.0
Junit 4.0
elliando dias
 
Introdução a testes unitários automatizados com JUnit e NUnit
Introdução a testes unitários automatizados com JUnit e NUnitIntrodução a testes unitários automatizados com JUnit e NUnit
Introdução a testes unitários automatizados com JUnit e NUnit
elliando dias
 
J unit xp
J unit xpJ unit xp
J unit xp
Emir Calife
 
Junit
JunitJunit
Testes de Unidade com JUnit
Testes de Unidade com JUnitTestes de Unidade com JUnit
Testes de Unidade com JUnit
elliando dias
 
JUnit: framework de testes unitários
JUnit: framework de testes unitáriosJUnit: framework de testes unitários
JUnit: framework de testes unitários
elliando dias
 
Introdução a tdd
Introdução a tddIntrodução a tdd
Introdução a tdd
Fabrício Vargas Matos
 
Testes de performance com JUnitPerf
Testes de performance com JUnitPerfTestes de performance com JUnitPerf
Testes de performance com JUnitPerf
Denis L Presciliano
 
JUnit Sample
JUnit SampleJUnit Sample
TDD (Resumo)
TDD (Resumo)TDD (Resumo)
TDD (Resumo)
Denis Ferrari
 
Aexo TI - Boas práticas de testes tdd
Aexo TI - Boas práticas de testes tddAexo TI - Boas práticas de testes tdd
Aexo TI - Boas práticas de testes tdd
Carlos Santana
 
JUnit - Selenium
JUnit - SeleniumJUnit - Selenium
JUnit - Selenium
Caue Guerra
 
Testes de Unidade com Junit
Testes de Unidade com JunitTestes de Unidade com Junit
Testes de Unidade com Junit
cejug
 
Test driven development
Test driven developmentTest driven development
Test driven development
Carlos Eduardo Miranda
 
Desenvolvimento Dirigido por Testes com Junit
Desenvolvimento Dirigido por Testes com JunitDesenvolvimento Dirigido por Testes com Junit
Desenvolvimento Dirigido por Testes com Junit
Adolfo Neto
 
Programação Defensiva
Programação DefensivaProgramação Defensiva
Programação Defensiva
Glaucio Scheibel
 
Python com TDD
Python com TDDPython com TDD
Python com TDD
Rodrigo Alves Vieira
 
Qualidade no desenvolvimento de software com PHPUnit
Qualidade no desenvolvimento de software com PHPUnitQualidade no desenvolvimento de software com PHPUnit
Qualidade no desenvolvimento de software com PHPUnit
Diego Tremper
 

Semelhante a Testes de Unidade com JUnit (20)

JUnit
JUnitJUnit
JUnit
 
Testes com JUnit
Testes com JUnitTestes com JUnit
Testes com JUnit
 
Junit 4.0
Junit 4.0Junit 4.0
Junit 4.0
 
Introdução a testes unitários automatizados com JUnit e NUnit
Introdução a testes unitários automatizados com JUnit e NUnitIntrodução a testes unitários automatizados com JUnit e NUnit
Introdução a testes unitários automatizados com JUnit e NUnit
 
J unit xp
J unit xpJ unit xp
J unit xp
 
Junit
JunitJunit
Junit
 
Testes de Unidade com JUnit
Testes de Unidade com JUnitTestes de Unidade com JUnit
Testes de Unidade com JUnit
 
JUnit: framework de testes unitários
JUnit: framework de testes unitáriosJUnit: framework de testes unitários
JUnit: framework de testes unitários
 
Introdução a tdd
Introdução a tddIntrodução a tdd
Introdução a tdd
 
Testes de performance com JUnitPerf
Testes de performance com JUnitPerfTestes de performance com JUnitPerf
Testes de performance com JUnitPerf
 
JUnit Sample
JUnit SampleJUnit Sample
JUnit Sample
 
TDD (Resumo)
TDD (Resumo)TDD (Resumo)
TDD (Resumo)
 
Aexo TI - Boas práticas de testes tdd
Aexo TI - Boas práticas de testes tddAexo TI - Boas práticas de testes tdd
Aexo TI - Boas práticas de testes tdd
 
JUnit - Selenium
JUnit - SeleniumJUnit - Selenium
JUnit - Selenium
 
Testes de Unidade com Junit
Testes de Unidade com JunitTestes de Unidade com Junit
Testes de Unidade com Junit
 
Test driven development
Test driven developmentTest driven development
Test driven development
 
Desenvolvimento Dirigido por Testes com Junit
Desenvolvimento Dirigido por Testes com JunitDesenvolvimento Dirigido por Testes com Junit
Desenvolvimento Dirigido por Testes com Junit
 
Programação Defensiva
Programação DefensivaProgramação Defensiva
Programação Defensiva
 
Python com TDD
Python com TDDPython com TDD
Python com TDD
 
Qualidade no desenvolvimento de software com PHPUnit
Qualidade no desenvolvimento de software com PHPUnitQualidade no desenvolvimento de software com PHPUnit
Qualidade no desenvolvimento de software com PHPUnit
 

Mais de Denis L Presciliano

Funmentos de Objetos Remotos
Funmentos de Objetos RemotosFunmentos de Objetos Remotos
Funmentos de Objetos Remotos
Denis L Presciliano
 
Fundamentos de JDBC
Fundamentos de JDBCFundamentos de JDBC
Fundamentos de JDBC
Denis L Presciliano
 
Como construir aplicações gráficas e applets
Como construir aplicações gráficas e appletsComo construir aplicações gráficas e applets
Como construir aplicações gráficas e applets
Denis L Presciliano
 
Classes internas
Classes internasClasses internas
Classes internas
Denis L Presciliano
 
Entrada e Saída
Entrada e SaídaEntrada e Saída
Entrada e Saída
Denis L Presciliano
 
Coleções Propriedade, Resources e Strings
Coleções Propriedade, Resources e StringsColeções Propriedade, Resources e Strings
Coleções Propriedade, Resources e Strings
Denis L Presciliano
 
Funcamentos de Programação Concorrente
Funcamentos de Programação ConcorrenteFuncamentos de Programação Concorrente
Funcamentos de Programação Concorrente
Denis L Presciliano
 
Erros, exceções e asserções
Erros, exceções e asserçõesErros, exceções e asserções
Erros, exceções e asserções
Denis L Presciliano
 
Interfaces e Porlimosfismo
Interfaces e PorlimosfismoInterfaces e Porlimosfismo
Interfaces e Porlimosfismo
Denis L Presciliano
 
Reuso com Herança e Composição
Reuso com Herança e ComposiçãoReuso com Herança e Composição
Reuso com Herança e Composição
Denis L Presciliano
 
Gerenciamento de projetos com o Apache Ant
Gerenciamento de projetos com o Apache AntGerenciamento de projetos com o Apache Ant
Gerenciamento de projetos com o Apache Ant
Denis L Presciliano
 
Pacotes e Encapsulamento
Pacotes e EncapsulamentoPacotes e Encapsulamento
Pacotes e Encapsulamento
Denis L Presciliano
 
Como criar classes e objetos
Como criar classes e objetosComo criar classes e objetos
Como criar classes e objetos
Denis L Presciliano
 
Tipos, literais, operadoes e controle de fluxo
Tipos, literais, operadoes e controle de fluxoTipos, literais, operadoes e controle de fluxo
Tipos, literais, operadoes e controle de fluxo
Denis L Presciliano
 
Como usar a documentação da API Java 2
Como usar a documentação da API Java 2Como usar a documentação da API Java 2
Como usar a documentação da API Java 2
Denis L Presciliano
 
Configuração do ambiente JEdit + Ant
Configuração do ambiente JEdit + AntConfiguração do ambiente JEdit + Ant
Configuração do ambiente JEdit + Ant
Denis L Presciliano
 
Programação Orientada a objetos em Java
Programação Orientada a objetos em JavaProgramação Orientada a objetos em Java
Programação Orientada a objetos em Java
Denis L Presciliano
 
Introdução a tecnologia Java
Introdução a tecnologia JavaIntrodução a tecnologia Java
Introdução a tecnologia Java
Denis L Presciliano
 
Fundamentos de Sockets
Fundamentos de SocketsFundamentos de Sockets
Fundamentos de Sockets
Denis L Presciliano
 
J530 15 workshop
J530 15 workshopJ530 15 workshop
J530 15 workshop
Denis L Presciliano
 

Mais de Denis L Presciliano (20)

Funmentos de Objetos Remotos
Funmentos de Objetos RemotosFunmentos de Objetos Remotos
Funmentos de Objetos Remotos
 
Fundamentos de JDBC
Fundamentos de JDBCFundamentos de JDBC
Fundamentos de JDBC
 
Como construir aplicações gráficas e applets
Como construir aplicações gráficas e appletsComo construir aplicações gráficas e applets
Como construir aplicações gráficas e applets
 
Classes internas
Classes internasClasses internas
Classes internas
 
Entrada e Saída
Entrada e SaídaEntrada e Saída
Entrada e Saída
 
Coleções Propriedade, Resources e Strings
Coleções Propriedade, Resources e StringsColeções Propriedade, Resources e Strings
Coleções Propriedade, Resources e Strings
 
Funcamentos de Programação Concorrente
Funcamentos de Programação ConcorrenteFuncamentos de Programação Concorrente
Funcamentos de Programação Concorrente
 
Erros, exceções e asserções
Erros, exceções e asserçõesErros, exceções e asserções
Erros, exceções e asserções
 
Interfaces e Porlimosfismo
Interfaces e PorlimosfismoInterfaces e Porlimosfismo
Interfaces e Porlimosfismo
 
Reuso com Herança e Composição
Reuso com Herança e ComposiçãoReuso com Herança e Composição
Reuso com Herança e Composição
 
Gerenciamento de projetos com o Apache Ant
Gerenciamento de projetos com o Apache AntGerenciamento de projetos com o Apache Ant
Gerenciamento de projetos com o Apache Ant
 
Pacotes e Encapsulamento
Pacotes e EncapsulamentoPacotes e Encapsulamento
Pacotes e Encapsulamento
 
Como criar classes e objetos
Como criar classes e objetosComo criar classes e objetos
Como criar classes e objetos
 
Tipos, literais, operadoes e controle de fluxo
Tipos, literais, operadoes e controle de fluxoTipos, literais, operadoes e controle de fluxo
Tipos, literais, operadoes e controle de fluxo
 
Como usar a documentação da API Java 2
Como usar a documentação da API Java 2Como usar a documentação da API Java 2
Como usar a documentação da API Java 2
 
Configuração do ambiente JEdit + Ant
Configuração do ambiente JEdit + AntConfiguração do ambiente JEdit + Ant
Configuração do ambiente JEdit + Ant
 
Programação Orientada a objetos em Java
Programação Orientada a objetos em JavaProgramação Orientada a objetos em Java
Programação Orientada a objetos em Java
 
Introdução a tecnologia Java
Introdução a tecnologia JavaIntrodução a tecnologia Java
Introdução a tecnologia Java
 
Fundamentos de Sockets
Fundamentos de SocketsFundamentos de Sockets
Fundamentos de Sockets
 
J530 15 workshop
J530 15 workshopJ530 15 workshop
J530 15 workshop
 

Último

História da Rádio- 1936-1970 século XIX .2.pptx
História da Rádio- 1936-1970 século XIX   .2.pptxHistória da Rádio- 1936-1970 século XIX   .2.pptx
História da Rádio- 1936-1970 século XIX .2.pptx
TomasSousa7
 
Manual-de-Credenciamento ANATER 2023.pdf
Manual-de-Credenciamento ANATER 2023.pdfManual-de-Credenciamento ANATER 2023.pdf
Manual-de-Credenciamento ANATER 2023.pdf
WELITONNOGUEIRA3
 
Segurança Digital Pessoal e Boas Práticas
Segurança Digital Pessoal e Boas PráticasSegurança Digital Pessoal e Boas Práticas
Segurança Digital Pessoal e Boas Práticas
Danilo Pinotti
 
Logica de Progamacao - Aula (1) (1).pptx
Logica de Progamacao - Aula (1) (1).pptxLogica de Progamacao - Aula (1) (1).pptx
Logica de Progamacao - Aula (1) (1).pptx
Momento da Informática
 
PRODUÇÃO E CONSUMO DE ENERGIA DA PRÉ-HISTÓRIA À ERA CONTEMPORÂNEA E SUA EVOLU...
PRODUÇÃO E CONSUMO DE ENERGIA DA PRÉ-HISTÓRIA À ERA CONTEMPORÂNEA E SUA EVOLU...PRODUÇÃO E CONSUMO DE ENERGIA DA PRÉ-HISTÓRIA À ERA CONTEMPORÂNEA E SUA EVOLU...
PRODUÇÃO E CONSUMO DE ENERGIA DA PRÉ-HISTÓRIA À ERA CONTEMPORÂNEA E SUA EVOLU...
Faga1939
 
TOO - TÉCNICAS DE ORIENTAÇÃO A OBJETOS aula 1.pdf
TOO - TÉCNICAS DE ORIENTAÇÃO A OBJETOS aula 1.pdfTOO - TÉCNICAS DE ORIENTAÇÃO A OBJETOS aula 1.pdf
TOO - TÉCNICAS DE ORIENTAÇÃO A OBJETOS aula 1.pdf
Momento da Informática
 
Escola Virtual - Fundação Bradesco - ITIL - Gabriel Faustino.pdf
Escola Virtual - Fundação Bradesco - ITIL - Gabriel Faustino.pdfEscola Virtual - Fundação Bradesco - ITIL - Gabriel Faustino.pdf
Escola Virtual - Fundação Bradesco - ITIL - Gabriel Faustino.pdf
Gabriel de Mattos Faustino
 

Último (7)

História da Rádio- 1936-1970 século XIX .2.pptx
História da Rádio- 1936-1970 século XIX   .2.pptxHistória da Rádio- 1936-1970 século XIX   .2.pptx
História da Rádio- 1936-1970 século XIX .2.pptx
 
Manual-de-Credenciamento ANATER 2023.pdf
Manual-de-Credenciamento ANATER 2023.pdfManual-de-Credenciamento ANATER 2023.pdf
Manual-de-Credenciamento ANATER 2023.pdf
 
Segurança Digital Pessoal e Boas Práticas
Segurança Digital Pessoal e Boas PráticasSegurança Digital Pessoal e Boas Práticas
Segurança Digital Pessoal e Boas Práticas
 
Logica de Progamacao - Aula (1) (1).pptx
Logica de Progamacao - Aula (1) (1).pptxLogica de Progamacao - Aula (1) (1).pptx
Logica de Progamacao - Aula (1) (1).pptx
 
PRODUÇÃO E CONSUMO DE ENERGIA DA PRÉ-HISTÓRIA À ERA CONTEMPORÂNEA E SUA EVOLU...
PRODUÇÃO E CONSUMO DE ENERGIA DA PRÉ-HISTÓRIA À ERA CONTEMPORÂNEA E SUA EVOLU...PRODUÇÃO E CONSUMO DE ENERGIA DA PRÉ-HISTÓRIA À ERA CONTEMPORÂNEA E SUA EVOLU...
PRODUÇÃO E CONSUMO DE ENERGIA DA PRÉ-HISTÓRIA À ERA CONTEMPORÂNEA E SUA EVOLU...
 
TOO - TÉCNICAS DE ORIENTAÇÃO A OBJETOS aula 1.pdf
TOO - TÉCNICAS DE ORIENTAÇÃO A OBJETOS aula 1.pdfTOO - TÉCNICAS DE ORIENTAÇÃO A OBJETOS aula 1.pdf
TOO - TÉCNICAS DE ORIENTAÇÃO A OBJETOS aula 1.pdf
 
Escola Virtual - Fundação Bradesco - ITIL - Gabriel Faustino.pdf
Escola Virtual - Fundação Bradesco - ITIL - Gabriel Faustino.pdfEscola Virtual - Fundação Bradesco - ITIL - Gabriel Faustino.pdf
Escola Virtual - Fundação Bradesco - ITIL - Gabriel Faustino.pdf
 

Testes de Unidade com JUnit

  • 1. Java 2 Standard Edition Testes de Unidade com JUnit Helder da Rocha (helder@acm.org) argonavis.com.br 1
  • 2. Sobre este módulo Este módulo é mais sobre boas práticas de desenvolvimento e menos sobre Java Abordagem será superficial (material é extenso), mas visa despertar seu interesse no hábito de escrever testes. Objetivos Apresentar e incentivar a prática de testes de unidade durante o desenvolvimento Apresentar a ferramenta JUnit, que ajuda na criação e execução de testes de unidade em Java Discutir as dificuldades relativas à "arte" de testar e como podem ser superadas ou reduzidas Torná-lo(a) uma pessoa "viciada" em testes: Convencêlo(a) a nunca escrever uma linha sequer de código sem antes escrever um teste executável que a justifique. 2
  • 3. O que é "Testar código"? É a coisa mais importante do desenvolvimento Se seu código não funciona, ele não presta! Todos testam Você testa um objeto quando escreve uma classe e cria algumas instâncias no método main() Seu cliente testa seu software quando ele o utiliza (ele espera que você o tenha testado antes) O que são testes automáticos? São programas que avaliam se outro programa funciona como esperado e retornam resposta tipo "sim" ou "não" Ex: um main() que cria um objeto de uma classe testada, chama seus métodos e avalia os resultados Validam os requisitos de um sistema 3
  • 4. Por que testar? Por que não? Como saber se o recurso funciona sem testar? Como saber se ainda funciona após refatoramento? Testes dão maior segurança: coragem para mudar Que adianta a OO isolar a interface da implementação se programador tem medo de mudar a implementação? Código testado é mais confiável Código testado pode ser alterado sem medo Como saber quando o projeto está pronto Testes == requisitos 'executáveis' Testes de unidade devem ser executados o tempo todo Escreva os testes antes. Quando todos rodarem 100%, o projeto está concluído! 4
  • 5. O que é JUnit? Um framework que facilita o desenvolvimento e execução de testes de unidade em código Java Uma API para construir os testes Aplicações para executar testes A API Classes Test, TestCase, TestSuite, etc. oferecem a infraestrutura necessária para criar os testes Métodos assertTrue(), assertEquals(), fail(), etc. são usados para testar os resultados Aplicação TestRunner Roda testes individuais e suites de testes Versões texto, Swing e AWT Apresenta diagnóstico sucesso/falha e detalhes 5
  • 6. Para que serve? 'Padrão' para testes de unidade em Java Desenvolvido por Kent Beck (XP) e Erich Gamma (GoF) Design muito simples Testar é uma boa prática, mas é chato; JUnit torna as coisas mais agradáveis, facilitando A criação e execução automática de testes A apresentação dos resultados JUnit pode verificar se cada unidade de código funciona da forma esperada Permite agrupar e rodar vários testes ao mesmo tempo Na falha, mostra a causa em cada teste Serve de base para extensões 6
  • 7. Arquitetura do JUnit Diagrama de classes Fonte: Manual do JUnit (Cooks Tour) 7
  • 8. Como usar o JUnit? Há várias formas de usar o JUnit. Depende da metodologia de testes que está sendo usada Código existente: precisa-se escrever testes para classes que já foram implementadas Desenvolvimento guiado por testes (TDD): código novo só é escrito se houver um teste sem funcionar Onde obter? www.junit.org Como instalar? Incluir o arquivo junit.jar no classpath para compilar e rodar os programas de teste Para este curso Inclua o junit.jar no diretório lib/ de seus projetos 8
  • 9. JUnit para testar código existente Exemplo de um roteiro típico 1. Crie uma classe que estenda junit.framework.TestCase para cada classe a ser testada import junit.framework.*; class SuaClasseTest extends TestCase {...} 2. Para cada método xxx(args) a ser testado defina um método public void testXxx() no test case SuaClasse: public boolean equals(Object o) { ... } SuaClasseTest: public void testEquals() {...} Sobreponha o método setUp(), se necessário Sobreponha o método tearDown(), se necessário 9
  • 10. JUnit para guiar o desenvolvimento Cenário de Test-Driven Development (TDD) 1. Defina uma lista de tarefas a implementar 2. Escreva uma classe (test case) e implemente um método de teste para uma tarefa da lista. 3. Rode o JUnit e certifique-se que o teste falha 4. Implemente o código mais simples que rode o teste Crie classes, métodos, etc. para que código compile Código pode ser código feio, óbvio, mas deve rodar! 5. Refatore o código para remover a duplicação de dados 6. Escreva mais um teste ou refine o teste existente 7. Repita os passos 2 a 6 até implementar toda a lista 10
  • 11. Como implementar? Dentro de cada teste, utilize os métodos herdados da classe TestCase assertEquals(objetoEsperado, objetoRecebido), assertTrue(valorBooleano), assertNotNull(objeto) assertSame(objetoUm, objetoDois), fail (), ... Exemplo de test case com um setUp() e um teste: public class CoisaTest extends TestCase { // construtor padrão omitido private Coisa coisa; public void setUp() { coisa = new Coisa("Bit"); } public void testToString() { assertEquals("<coisa>Bit</coisa>", coisa.toString()); } } 11
  • 12. Como funciona? O TestRunner recebe uma subclasse de junit.framework.TestCase Usa reflection (Cap 14) para achar métodos TestCase setUp() tearDown() Para cada método testXXX(), executa: 1. o método setUp() 2. o próprio método testXXX() 3. o método tearDown() O test case é instanciado para executar um método testXXX() de cada vez. MeuTestCase setUp() testXXX() testYYY() tearDown() As alterações que ele fizer ao estado do objeto não afetarão os demais testes Método pode terminar, falhar ou provocar exceção 12
  • 13. Exemplo: um test case package junitdemo; import junit.framework.*; import java.io.IOException; Construtor precisa ser publico, receber String name e chamar super(String name) public class TextUtilsTest extends TestCase { public TextUtilsTest(String name) { super(name); } (JUnit 3.7 ou anterior) Método começa com "test" e é sempre public void public void testRemoveWhiteSpaces() throws IOException { String testString = "one, ( two | three+) , "+ "(((four+ |t five)?n n, six?"; String expectedString = "one,(two|three+)"+ ",(((four+|five)?,six?"; String results = TextUtils.removeWhiteSpaces(testString); assertEquals(expectedString, results); } } 13
  • 14. Exemplo: uma classe que faz o teste passar package junitdemo; import java.io.*; public class TextUtils { public static String removeWhiteSpaces(String text) throws IOException { return "one,(two|three+),(((four+|five)?,six?"; } } O teste passa... e daí? A solução está pronta? Não! Tem dados duplicados! Remova-os! Escreva um novo teste que faça com que esta solução falhe, por exemplo: String test2 = " a bnc "; assertEquals("abc", TextUtils.removeWhiteSpaces(test2)); 14
  • 15. Outra classe que faz o teste passar package junitdemo; import java.io.*; public class TextUtils { public static String removeWhiteSpaces(String text) throws IOException { StringReader reader = new StringReader(text); StringBuffer buffer = new StringBuffer(text.length()); int c; while( (c = reader.read()) != -1) { if (c ==' '||c =='n'||c =='r'|| c =='f'||c =='t') { ; /* do nothing */ } else { buffer.append((char)c); } } return buffer.toString(); } } 15
  • 16. Exemplo: como executar Use a interface de texto java -cp junit.jar junit.textui.TestRunner junitdemo.TextUtilsTest Ou use a interface gráfica java -cp junit.jar junit.swingui.TestRunner junitdemo.TextUtilsTest Use Ant <junit> tarefa do Apache Ant Ou forneça um main(): public static void main (String[] args) { TestSuite suite = new TestSuite(TextUtilsTest.class); junit.textui.TestRunner.run(suite); } 16
  • 17. TestSuite Permite executar uma coleção de testes Método addTest(TestSuite) adiciona um teste na lista Padrão de codificação (usando reflection): retornar um TestSuite em cada test-case: public static TestSuite suite() { return new TestSuite(SuaClasseTest.class); } criar uma classe AllTests que combina as suites: public class AllTests { public static Test suite() { TestSuite testSuite = Pode incluir new TestSuite("Roda tudo"); outras suites testSuite.addTest(pacote.AllTests.suite()); testSuite.addTest(MinhaClasseTest.suite()); testSuite.addTest(SuaClasseTest.suite()); return testSuite; } 17 }
  • 18. Fixtures São os dados reutilizados por vários testes public class AttributeEnumerationTest extends TestCase { String testString; String[] testArray; Fixture AttributeEnumeration testEnum; public void setUp() { testString = "(alpha|beta|gamma)"; testArray = new String[]{"alpha", "beta", "gamma"}; testEnum = new AttributeEnumeration(testArray); } public void testGetNames() { assertEquals(testEnum.getNames(), testArray); } public void testToString() { assertEquals(testEnum.toString(), testString); } (...) Se os mesmos dados são usados em vários testes, inicialize-os no setUp() e faça a faxina no tearDown() (se necessário) Não perca tempo pensando nisto antes. Escreva seus testes. Depois, se achar que há duplicação, monte o fixture. 18
  • 19. Teste situações de falha É tão importante testar o cenário de falha do seu codigo quanto o sucesso Método fail() provoca uma falha Use para verificar se exceções ocorrem quando se espera que elas ocorram Exemplo public void testEntityNotFoundException() { resetEntityTable(); // no entities to resolve! try { // Following method call must cause exception! ParameterEntityTag tag = parser.resolveEntity("bogus"); fail("Should have caused EntityNotFoundException!"); } catch (EntityNotFoundException e) { // success: exception occurred as expected } } 19
  • 20. JUnit vs. asserções Afirmações do J2SDK 1.4 são usadas dentro do código Podem incluir testes dentro da lógica procedural de um programa if (i%3 == 0) { doThis(); } else if (i%3 == 1) { doThat(); } else { assert i%3 == 2: "Erro interno!"; } Provocam um AssertionError quando falham (que pode ser encapsulado pelas exceções do JUnit) Afirmações do JUnit são usadas em classe separada (TestCase) Não têm acesso ao interior dos métodos (verificam se a interface dos métodos funciona como esperado) Afirmações do J2SDK1.4 e JUnit são complementares JUnit testa a interface dos métodos assert testa trechos de lógica dentro dos métodos 20
  • 21. Limitações do JUnit Acesso aos dados de métodos sob teste Métodos private e variáveis locais não podem ser testadas com JUnit. Dados devem ser pelo menos package-private (friendly) Soluções com refatoramento Isolar em métodos private apenas código inquebrável Transformar métodos private em package-private Desvantagem: quebra ou redução do encapsulamento Classes de teste devem estar no mesmo pacote que as classes testadas para ter acesso Solução usando extensão do JUnit (open-source) JUnitX: usa reflection para ter acesso a dados private http://www.extreme-java.de/junitx/index.html 21
  • 22. Resumo: JUnit Para o JUnit, Um teste é um método Um caso de teste é uma classe contendo uma coleção de testes (métodos que possuem assertions) Cada teste testa o comportamento de uma unidade de código do objeto testado (pode ser um método, mas pode haver vários testes para o mesmo método ou um teste para todo o objeto) Fixtures são os dados usados em testes TestSuite é uma composição de casos de teste Pode-se agrupar vários casos de teste em uma suite JUnit testa apenas a interface das classes Mantenha os casos de teste no mesmo diretório que as classes testadas para ter acesso a métodos package-private Use padrões de nomenclatura: ClasseTest, AllTests Use o Ant para separar as classes em um release 22
  • 23. Apêndice: boas práticas e dificuldades com testes 23
  • 24. Como escrever bons testes JUnit facilita bastante a criação e execução de testes, mas elaborar bons testes exige mais O que testar? Como saber se testes estão completos? "Teste tudo o que pode falhar" [2] Métodos triviais (get/set) não precisam ser testados. E se houver uma rotina de validação no método set? É melhor ter testes a mais que testes a menos Escreva testes curtos (quebre testes maiores) Use assertNotNull() (reduz drasticamente erros de NullPointerException difíceis de encontrar) Reescreva seu código para que fique mais fácil de testar 24
  • 25. Como descobrir testes? Escreva listas de tarefas (to-do list) Comece pelas mais simples e deixe os testes "realistas" para o final Requerimentos, use-cases, diagramas UML: rescreva os requerimentos em termos de testes Dados Use apenas dados suficientes (não teste 10 condições se três forem suficientes) Bugs revelam testes Achou um bug? Não conserte sem antes escrever um teste que o pegue (se você não o fizer, ele volta)! Teste sempre! Não escreva uma linha de código sem antes escrever um teste! 25
  • 26. Test-Driven Development (TDD) Desenvolvimento guiado pelos testes Só escreva código novo se um teste falhar Refatore até que o teste funcione Alternância: "red/green/refactor" - nunca passe mais de 10 minutos sem que a barra do JUnit fique verde. Técnicas "Fake It Til You Make It": faça um teste rodar simplesmente fazendo método retornar constante Triangulação: abstraia o código apenas quando houver dois ou mais testes que esperam respostas diferentes Implementação óbvia: se operações são simples, implemente-as e faça que os testes rodem 26
  • 27. Como lidar com testes difíceis Testes devem ser simples e suficientes XP: design mais simples que resolva o problema; sempre pode-se escrever novos testes, quando necessário Não complique Não teste o que é responsabilidade de outra classe/método Assuma que outras classes e métodos funcionam Testes difíceis (ou que parecem difíceis) Aplicações gráficas: eventos, layouts, threads Objetos inaccessíveis, métodos privativos, Singletons Objetos que dependem de outros objetos Objetos cujo estado varia devido a fatores imprevisíveis Soluções Alterar o design da aplicação para facilitar os testes Simular dependências usando proxies e stubs 27
  • 28. Dependência de código-fonte Problema Como testar componente que depende do código de outros componentes? Tanque Classe-alvo não oferece o que testar: +nivel() CarroTest Carro +testAcelera() +acelera() Ignição +ligada() Método acelera() só vai funcionar se nível() do tanque for > 0 public void testAcelera() { e ignição estiver ligada() Carro carro = new Carro(); Como saber se condições são carro.acelera(); verdadeiras se não temos assert???(???); } acesso às dependências? Fonte: www.objectmentor.com, 2002 28
  • 29. Stubs: objetos "impostores" É possível remover dependências de código-fonte refatorando o código para usar interfaces depois antes A B «interface» InterB A A não conhece mais o tipo concreto de B B Agora B pode ser substituída por um stub BStub está sob controle total de ATest (1) Em alguns casos, ATest pode implementar InterB (2) ATest A «interface» InterB A «interface» InterB (2) (1) « cria » ATest BStub Fonte: www.objectmentor.com, 2002 B self-shunt pattern B 29
  • 30. Dependência: solução usando stubs «interface» Tanque +nivel():float "Mock implementation" das dependências simula os efeitos que terão sobre Carro CarroTest +testTanqueVazioSemIgn() +testTanqueCheioSemIgn() +testTanqueVazioComIgn() +testTanqueCheioComIgn() TanqueImpl +nivel():float Carro +acelera() «interface» Ignicao +ligada(): bool IgnicaoImpl +ligada():bool Quando criar o objeto, passe a implementação falsa carro.setTanque(new CarroTest()); carro.setIgnicao(new CarroTest()); Depois preencha-a com dados suficientes para que objeto possa ser testado Fonte: www.objectmentor.com, 2002 30
  • 31. Dependências de servidores Usar stubs para simular serviços e dados É preciso implementar classes que devolvam as respostas esperadas para diversas situações Complexidade muito grande da dependência pode não compensar investimento (não deixe de fazer testes por causa disto!) Vários tipos de stubs: mock objects, self-shunts. Usar proxies (mediadores) para serviços reais Oferecem interface para simular comunicação e testa a integração real do componente com seu ambiente Não é teste unitário: teste pode falhar quando código está correto (se os fatores externos falharem) Exemplo em J2EE: Jakarta Cactus 31
  • 32. Mock Objects Mock objects (MO) é uma estratégia de uso de stubs que não implementa nenhuma lógica Um mock object não é exatamente um stub, pois não simula o funcionamento do objeto em qualquer situação Comportamento é controlado pela classe de teste que Define comportamento esperado (valores retornados, etc.) Passa MO configurado para objeto a ser testado Chama métodos do objeto (que usam o MO) Implementações open-source que facilitam uso de MOs EasyMock (tammofreese.de/easymock/) e MockMaker (www.xpdeveloper.com) geram MOs a partir de interfaces Projeto MO (mockobjects.sourceforge.net) coleção de mock objects e utilitários para usá-los 32
  • 33. Ant + JUnit Com Ant, pode-se executar todos os testes após a integração com um único comando: ant roda-testes Com as tarefas <junit> e <junitreport> é possível executar todos os testes gerar um relatório simples ou detalhado, em diversos formatos (XML, HTML, etc.) executar testes de integração São tarefas opcionais. É preciso ter em $ANT_HOME/lib optional.jar (distribuído com Ant) junit.jar (distribuído com JUnit) 33
  • 34. Exemplo: <junit> <target name="test" depends="build"> <junit printsummary="true" dir="${build.dir}" fork="true"> <formatter type="plain" usefile="false" /> <classpath path="${build.dir}" / <test name="argonavis.dtd.AllTests" /> </junit> Formata os dados na tela (plain) </target> Roda apenas arquivo AllTests <target name="batchtest" depends="build" > <junit dir="${build.dir}" fork="true"> <formatter type="xml" usefile="true" /> <classpath path="${build.dir}" /> <batchtest todir="${test.report.dir}"> <fileset dir="${src.dir}"> <include name="**/*Test.java" /> <exclude name="**/AllTests.java" /> </fileset> </batchtest> Gera arquivo XML </junit> Inclui todos os arquivos que </target> terminam em TEST.java 34
  • 35. <junitreport> Gera um relatório detalhado (estilo JavaDoc) de todos os testes, sucessos, falhas, exceções, tempo, ... <target name="test-report" depends="batchtest" > <junitreport todir="${test.report.dir}"> <fileset dir="${test.report.dir}"> Usa arquivos XML <include name="TEST-*.xml" /> gerados por </fileset> <formatter> <report todir="${test.report.dir}/html" format="frames" /> </junitreport> </target> 35
  • 36. Resumo Testar é tarefa essencial do desenvolvimento de software. Testar unidades de código durante o desenvolvimento é uma prática que traz inúmeros benefícios Menos tempo de depuração (muito, muito menos!) Melhor qualidade do software Segurança para alterar o código Usando TDD, melhores estimativas de prazo JUnit é uma ferramenta open-source que ajuda a implementar testes em projetos Java TDD ou Test-Driven Development é uma técnica onde os testes são usados para guiar o desenvolvimento Ajuda a focar o desenvolvimento em seus objetivos Mock objects ou stubs podem ser usados para representar dependência e diminuir as responsabilidades de testes 36
  • 37. Exercício 1. A classe Exercicio.java possui quatro métodos vazios: int soma(int a, int b) long fatorial(long n); double fahrToCelsius(double fahrenheit); String inverte(String texto); Escreva, na classe ExercicioTest.java, test-cases para cada método, que preencham os requisitos: Soma: 1+1 = 2, 2+4 = 4 Fatorial: 0! = 1, 1! = 1, 2! = 2, 3! = 6, 4! = 24, 5! = 120 A fórmula é n! = n(n-1)(n-2)(n-3)...3*2*1 Celsius: -40C = -40F, 0C=32F, 100C=212F A fórmula é F = 9/5 * C + 32 Inverte recebe "Uma frase" e retorna "esarf amU" Implemente um teste e execute-o (o esqueleto de um deles já está pronto). Ele deve falhar. Implemente os métodos, um de cada vez, e rode os testes até que não falhem mais (tarja verde), antes de prosseguir. 37
  • 38. Curso J100: Java 2 Standard Edition Revisão 17.0 © 1996-2003, Helder da Rocha (helder@acm.org) argonavis.com.br 38