Só um cadiquinho de TDD

1. [ TDD]
Test Driven Development
Autor: Eduardo R. Carvalho
email: ercarval@gmail.com
@ercarval
Autor: Eduardo R. Carvalho
Facebook : ercarval
email: ercarval@gmail.com
$ 1.0

2. [ TDD ]
• O que é
• Metodologia
• Testes e Ciclo de Desenvolvimento de SW
• JUnit
• JUnit & NetBeans
• Best Practices
• Resumo
6/4/2012 Eduardo R Carvalho 2

3. [TDD] – Test-Driven Development
• Metodologia que utiliza de Testes para prover informações para
tomada decisões de forma rápida e eficaz.
• Promove o desenvolvimento de software de uma maneira simples
e incremental. Não somente maximiza a qualidade e o design do
software, como também simplifica o processo de
desenvolvimento.
• TDD é uma das práticas do Extreme Programming (XP). As práticas
do XP foram formuladas por Kent Beck e Ron Jeffries a partir de
suas experiências no desenvolvimento de uma sistema de
pagamento para a Chrysler. As idéias gerais por trás do XP são
simplificar o processo de desenvolvimento simples e manter um
processo contínuo de desenvolvimento em um ciclo curto que
fornece um feedback constante do estado do software. As idéias
do TDD tem ganho uma grande aceitação nos meio dos
desenvolvimento e projetos de software.
6/4/2012 Introução a Java 3

4. [TDD] - Metodologia
 Baseada em dois Conceitos Básicos.
 Testes Unitários
 “Refactoring”
 Composto nos seguintes passos:
1. Escrever um teste que define como você acha que pequeno
pedaço da aplicação deveria se comportar.
2. Fazer o teste rodar da maneira mais fácil e rápida que você
pode. Não se preocupe com a qualidade do código, apenas
faça funcionar.
3. Enxugue o código. Agora que o código esta funcionando
corretamente, dê um passo para trás e refatore para
remover qualquer duplicação ou qualquer outro problema
que foi apresentado para tornar o teste executável.
6/4/2012 Introução a Java 4

5. [TDD] - Metodologia
 TDD é um processo iterativo e você repete estes passos
inúmeras vezes até que você fique satisfeito com o novo código.
 A maneira que TDD trabalha é através de requisitos, ou casos de
uso que são decompostos em um conjunto de comportamentos
que são premissas para atender o requisito.
Para cada comportamento do sistema, a primeira coisa a se
fazer é escrever um teste unitário que irá testar este
comportamento. O teste unitário primeiro, portanto temos um
conjunto bem definido de critérios que podemos utilizar para
mensurar a quantidade de código necessário que foi escrito para
implementar este comportamento. Um dos benefícios de se
escrever o teste primeiro é que ele ajuda a definir o
comportamento do sistema de uma maneira mais clara e
responder algumas perguntas do modelo.
6/4/2012 Introução a Java 5

6. [TDD] - Como Adotar ?
 Convencendo as pessoas a utilizar TDD
Desenvolver software é um risco assumido. É quase impossível
entregar um projeto dentro do orçamento e do prazo. De acordo
com um estudo da Gartner Group, 30% dos projetos falham e
não chegam aos seus objetivos, e 70% são entregues em atraso
ou fora do orçamento previsto. Claramente existe a necessidade
de melhorar este processo, mas a questão é como. TDD pode
ser parte da resposta, mas antes de convencer as pessoas a
utilizar TDD é preciso entender e apresentar os problemas do
processo atual. Uma vez entendido as falhas do processo
corrente, é preciso entender como utilizar TDD para suprir estas
falhas e utilizar este conhecimento para convencer as outras
pessoas que isso irá funcionar.
6/4/2012 Introução a Java 6

7. [TDD] - Como Adotar ?
 Encontrando as falhas no processo corrente.
O processo mais usual quando não se pratica TDD é o famoso
modelo cascata ( análise dos requisitos, modelo, código e o
teste). A maioria dos problemas relacionados ao
desenvolvimento de software é má comunicação da equipe e
uma execução falha. Para entender as falhas do processo
corrente, devemos responder algumas perguntas básicas como:
– Qual é a maior causa dos bugs no softwares ?
– Qual é a maor causa dos atrasos no cronograma ?
– Qual é a média de bugs a cada 1000 linhas de código escrito ?
– Como o processo reage a uma mudança de requisito.
– Qual a fase do projeto que mais tenho problemas ?
(Desing, código, integração, etc..)
6/4/2012 Introução a Java 7

8. [TDD] - Testes no ciclo de vida do SW
 Testes formais podem e devem ser definidos em todas as etapas do desenvolvimento de um
software. Mesmo no caso de não poderem ser automatizados, defini-los precisamente permite
identificar desde cedo problemas mais sérios com os requisitos ou a modelagem de uma aplicação.
Podemos dizer que, quando faltam informações para a definição formal de um teste em termos de
entradas exatas e de resultados esperados, isso significa que os requisitos ainda não foram
suficientemente entendidos e documentados.
 Passado o levantamento de requisitos e a modelagem de negócios de uma aplicação, os testes
passam a se focar mais em aspectos particulares da implementação, o que aumenta a demanda pela
sua automação. Neste momento, a falta de informações suficientes para se implementar um teste
automatizado pode indicar que as especificações de classes, pacotes, componentes, formatos de
dados etc. ainda estão incompletas, ou então que surgiram requisitos novos ainda não
completamente documentados.
 O desenvolvimento orientado a testes traz o benefício de validar de modo objetivo os requisitos
documentados desde o início do ciclo de vida. O TDD expõe erros, omissões e inconsistências que de
outra forma só seriam detectados quando já houvesse código executável entregue ao usuário.
6/4/2012 Introução a Java 8

9. [TDD] - Testes no ciclo de vida do SW
 Um exemplo de processo de desenvolvimento e os tipos de testes que são produzidos em cada
etapa. Vale a pena ressaltar aqui que em muitos casos as mesmas tecnologias e ferramentas podem
ser utilizadas para construir diferentes tipos de testes. A distinção entre, por exemplo, “testes de
unidade” e “testes de sistema” é feita em relação à finalidade de cada teste, e não em relação à sua
forma.
6/4/2012 Introução a Java 9

10. [TDD] Alguns Frameworks de apoio
 JUnit
 http://www.junit.org
 EasyMock
 http://easymock.org
 JMock
 http://www.jmock.org/
 Mockito
 http://code.google.com/p/mockito/
 Spring
 http://www.springsource.org/
 iMacros
 http://www.iopus.com/download/
6/4/2012 Introução a Java 10

11. [TDD] – JUnit : O que é ?
 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.
 Suportado por varias IDES (Eclipse, NetBeans, JDeveloper, etc...).
6/4/2012 Introução a Java 11

12. [TDD] – JUnit : Para que Serve ?
 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/4/2012 Introução a Java 12

13. [TDD] – JUnit : Arquitetura
 Diagrama de Classes
6/4/2012 Introução a Java 13

14. [TDD] – JUnit : Como Usar ?
 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
6/4/2012 Introução a Java 14

15. [TDD] – JUnit : 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() {...}
 Sobre escreva o método setUp(), se necessário
 Sobre escreva o método tearDown(), se necessário
6/4/2012 Introução a Java 15

16. [TDD] – JUnit : Guiar 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
6/4/2012 Introução a Java 16

17. [TDD] – JUnit : 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:
1. public class CoisaTest extends TestCase {
2. // construtor padrão omitido
3. private Coisa coisa;
4. public void setUp(){ coisa = new Coisa("Bit"); }
5. public void testToString() {
6. assertEquals("<coisa>Bit</coisa>",
7. coisa.toString() );
8. }
9. }
6/4/2012 Eduardo R Carvalho 17

18. [TDD] – JUnit : Como Funciona ?
 O TestRunner recebe uma subclasse de junit.framework.TestCase
 Usa reflection para achar métodos
 Para cada método testXXX(), executa:
 o método setUp()
 o próprio método testXXX()
 o método tearDown()
 O test case é instanciado para executar um método testXXX() de
cada vez.
 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
6/4/2012 Eduardo R Carvalho 18

19. [TDD] – JUnit : Exemplo de Test Case
package junitdemo;
import junit.framework.*;
import java.io.IOException;
public class TextUtilsTest extends TestCase {
public TextUtilsTest(String name) {
super(name);
}
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);
}
}
6/4/2012 Eduardo R Carvalho 19

20. [TDD] – JUnit : Fazendo o Teste Passar
1. package junitdemo;
2. import java.io.*;
3. public class TextUtils {
4. public static String removeWhiteSpaces(String text) throws ...{
5. return "one,(two|three+),(((four+|five)?,six?";
6. }
7. }
 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));
6/4/2012 Eduardo R Carvalho 20

21. [TDD] – JUnit : Fazendo o Teste Passar!!
1. package junitdemo;
2. import java.io.*;
3. public class TextUtils {
4. public static String removeWhiteSpaces(String text)
5. throws IOException {
6. StringReader reader = new StringReader(text);
7. StringBuffer buffer = new StringBuffer(text.length());
8. int c;
9. while( (c = reader.read()) != -1) {
10. if (c ==' '||c =='n'||c =='r'|| c =='f'||c =='t') {
11. ; /* do nothing */
12. } else {
13. buffer.append((char)c);
14. }
15. }
16. return buffer.toString();
17. }
18.}
6/4/2012 Eduardo R Carvalho 21

22. [TDD] – JUnit : 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:
1. public static TestSuite suite() {
2. return new TestSuite(SuaClasseTest.class);
3. }
 Criar uma classe AllTests que combina as suites:
1. public class AllTests {
2. public static Test suite() {
3. TestSuite testSuite = new TestSuite("Roda tudo");
4. testSuite.addTest(pacote.AllTests.suite());
5. testSuite.addTest(MinhaClasseTest.suite());
6. testSuite.addTest(SuaClasseTest.suite());
7. return testSuite;
8. }
9. }
6/4/2012 Eduardo R Carvalho 22

23. [TDD] – JUnit : Fixture
 São os dados reutilizados por vários testes
1. public class AttributeEnumerationTest extends TestCase {
2. String testString; String[] testArray;
3. AttributeEnumeration testEnum;
4. public void setUp() {
5. testString = "(alpha|beta|gamma)";
6. testArray = new String[]{"alpha", "beta", "gamma"};
7. testEnum = new AttributeEnumeration(testArray);
8. }
9. public void testGetNames() {
10. assertEquals(testEnum.getNames(), testArray);
11. }
12. public void testToString() {
13. assertEquals(testEnum.toString(), testString);
14. }
15. ....
 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.
6/4/2012 Eduardo R Carvalho 23

24. [TDD] – JUnit : Testando a 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:
1. public void testEntityNotFoundException() {
2. resetEntityTable(); // no entities to resolve!
3. try {
4. // Following method call must cause exception!
5. ParameterEntityTag tag = parser.resolveEntity("bogus");
6. fail("Should have caused EntityNotFoundException!");
7. } catch (EntityNotFoundException e) {
8. // success: exception occurred as expected
9. }
10.}
6/4/2012 Eduardo R Carvalho 24

25. [TDD] – JUnit : Resumo
 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
6/4/2012 Eduardo R Carvalho 25

26. [TDD] – JUnit : NetBeans 6.7.x
 http://junit.netbeans.org/proposed-new-features.html
6/4/2012 Eduardo R Carvalho 26

27. [TDD] – JUnit 4 : Simple Test
1. public class DAOTest {
2. @BeforeClass
3. public static void setUpClass() throws Exception { }
4. @AfterClass
5. public static void tearDownClass() throws Exception {}
6. @Before
7. public void setUp() {}
8. @After
9. public void tearDown() {}
10. @Test
11. public void testXXX() { }
12. @Test
13. public void testYYY() { }
14.}
6/4/2012 Eduardo R Carvalho 27

28. [TDD] – JUnit 4 : TestSuite
1. @RunWith(Suite.class)
2. @Suite.SuiteClasses( {br.com.fastbuy.dao.ItemDAOTest.class ,
3. br.com.fastbuy.framework.dao.DAOHelperTest.class })
4. public class SampleTestSuite {
5. @BeforeClass
6. public static void setUpClass() throws Exception {}
7. @AfterClass
8. public static void tearDownClass() throws Exception {}
9. @Before
10. public void setUp() throws Exception {}
11. @After
12. public void tearDown() throws Exception {}
13.}
6/4/2012 Eduardo R Carvalho 28

29. [TDD] – Best Practices
 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
6/4/2012 Eduardo R Carvalho 29

30. [TDD] – Best Practices
 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!
6/4/2012 Eduardo R Carvalho 30

31. [TDD] – Test-Driven Development
 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
6/4/2012 Eduardo R Carvalho 31

32. [TDD] – 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 inacessí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
6/4/2012 Eduardo R Carvalho 32

33. [TDD] – 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
6/4/2012 Eduardo R Carvalho 33