Test Driven Development Eloi Rocha Neto, 06/10/2007

Introdução Por que precisamos testar? Como saber se o que fizemos está correto ou não? Como garantir se o que está compilado funciona? Será que é possível um projeto estar concluído se não tiver sido testado?

Introdução Como testamos nosso código? testes manuais? e quando o código fica muito grande? e quando fazemos mudanças no nosso código, teremos que testar tudo novamente? podemos esquecer de testar algo importante!!! e quando encontramos um bug, o que isso significa?

Introdução O que queremos? queremos fazer alterações em nosso código, e saber, ao final, se inserimos algum bug no código não queremos perder conhecimento importante sobre como testar o código queremos testes automáticos queremos um botão mágico que roda todos os testes automaticamente e informa se eles passaram ou não!

Introdução Por que testes automáticos são importantes? dão coragem para mudar (podem ser alterados sem medo) códigos frequentemente testados são mais confiáveis testes representam patrimônio da empresa testes podem ser interpretados como uma parte da documentação

Introdução Por que testes automáticos são importantes? (cont.) se todos os requisitos do sistema forem transformados em testes, então o projeto estará pronto, quando todos os testes passarem

Introdução Existem vários tipos de testes Foco: Testes de Unidade Testes de Regressão Testes de Integração Testes Funcionais Foco: Testes de Unidade

Introdução Do que precisamos para começar? Um ferramenta que nos auxilie a desenvolver e testar nossos testes de unidade

JUnit Um framework para construção / execução de testes de unidade em Java Como funciona? Criamos uma classe e escrevemos um conjunto de métodos contendo verificações Cada verificação avalia se o comportamento do código sendo testado é o esperado Exemplo: se o resultado de um método que realizada a soma de “3 + 4” é igual a “7”.

JUnit Como funciona? (cont.) Requisitos que um teste deve atender: Cada método de teste deve possuir a anotação @Test Quando for fazer uma asserção dentro do método, utilizar um conjunto de métodos disponibilizados pelo JUnit; entre eles: assertTrue, assertFalse, assertSame, assertNull, assertNotNull, … Esses métodos devem ser importados estaticamente de org.junit.Assert.*

JUnit Seja a seguinte classe: public class Calculadora { public int somar(int a,int b) { return a + b; }

JUnit Seja um teste para a classe Calculadora: ... import static org.junit.Assert.assertEquals; import static org.junit.Assert.assertTrue; public class MeuPrimeiroTeste { @Test public void somar() { Calculadora calc = new Calculadora(); assertTrue( calc.somar(3,45) == 48 ); assertEquals( 9, calc.dividir(18,2) ); } @Test public void ...

JUnit Outras anotações que também podem ser utilizadas em um método de teste: @Before @After @BeforeClass @AfterClass @Test (expected=Exception.class) @Test (timeout=int) @Ignore

JUnit Exemplo: ... @Test(expected=DivisaoPorZeroException.class) public void dividirPorZero() { int n = 2 / 0; } @Before public void zerarConta() { conta = new Conta(); @After public void fecharConexao() { conexao.close();

JUnit Comentários importantes quando testamos, não podemos ter pena do código o cliente não terá! precisamos esquecer um pouco do nosso afeto ao bebê!!! precisamos testar: entradas erradas / inconsistentes / nulas precisamos avaliar todas as facetas do código!!! Idealmente, monte um fluxograma contendo tudo a ser testado!

JUnit Lembrem que da mesma forma que queremos nosso código limpo, nossos testes também devem estar Código limpo é mais fácil de entender Um teste seguindo boas práticas de programação fica mais claro, permite testar mais com menos linhas de código

JUnit Como rodamos um teste? Precisamos executar o TestRunner executa todos os métodos que possuem a anotação @Test se existir um método com a anotação @Before/@After, ele será executado antes/depois de cada teste se existir um método com a anotação @BeforeClass/@AfterClass, ele será executado no início/final do teste (só será executado uma vez)

JUnit Usando linha de comando: java -cp junit-4.4.jar;. junit.swingui.Test MeuTest

JUnit Pergunta: quando escrever os testes? Escrever o código todo e depois testar? Escrever o código e testar ao mesmo tempo? Escrever os testes e depois codificar?!?

TDD Test Driven Development (TDD) é uma técnica de desenvolvimento de software cujo mantra consiste em escrever um teste, escrever um código simples para fazer o teste passar e, ao final, refatorar o código.

TDD Mantra do TDD: Escrever um teste Codificar o mínimo o possível para o teste passar Refatorar

TDD Testes devem ser feitos em pequenos passos Nunca se codifica sem ter um teste antes! se não, ele volta e pega você! Quando encontrar um bug, crie um teste antes que prove a existência do bug, depois corrija-o.

TDD Testes: documentação executável! Execute-os periodicamente Use nomes apropriados Mantenha-os simples Todas as asserções do JUnit possui um argumento para descrever o que está sendo testado assertEquals( “Saldo não é zero!”, 0, conta.getSaldo() ); assertNull( “Conta não é Null!” , conta );

TDD Quando escrevemos um teste antes de codificar estamos pensando em: design teste documentação

TDD Problema: deseja-se construir um sorteador com os seguintes requisitos: Um jogador poderá fazer diversas apostas (cada aposta consiste de quatro números) Custo de uma aposta para o jogador: R$ 10,00 Não pode existir números repetidos na aposta Intervalo de números possíveis: [1, 2, 3, ..., 20] Saldo inicial do sorteador é R$100,00 Quando o jogador é sorteado, isto é, o quarteto apostado é o sorteado, todo dinheiro do sorteador passa a ser do jogador. Caso mais de um jogador seja sorteado, o prêmio é dividido.

TDD Quando estamos escrevendo testes, o que nós realmente queremos? testes bem focados: queremos testes partes específicas de nossas aplicações; testes independentes: queremos que nossos testes rodem em qualquer ordem e a qualquer momento; testes rápidos: queremos que nossos testes sejam rodados frequentemente.

TDD Infelizmente, o mundo é cruel e nossas vontades se deparam com as seguintes dificuldades: testes bem focados implicam em uma grande quantidade de testes; torná-los independentes necessite de uma forma eficiente de limpar os objetos utilizados (uma vez que esses objetos podem ser utilizados por outros testes); testar partes isoladas de aplicações complexas não é uma tarefa trivial

TDD Mock Objects tem o objetivo de simplificar ou amenizar esta problemática. Mock Objects são utilizados quando é difícil ou impossível criar um determinado estado do sistema sendo testado, ou quando o acesso ao recurso é limitado. O princípio básico atrás de mocks é criar objetos leves e controláveis para simplificar a construção de seus testes.

TDD Devemos criar mocks nas seguintes situações: Deixar os testes mais focados Fazer com que os testes rodem mais rápidos Simplificar o desenvolvimento de aplicações que conversam com hardware, dispositivos remotos, ou mesmo, com outras aplicações.

TDD Devemos criar mocks nas seguintes situações (cont.): Promover um desenvolvimento baseado em uma interface Encorajar o uso de composição em vez de herança Testar situações incomuns

<eloi.rocha@gmail.com> Muito obrigado pela atenção! <eloi.rocha@gmail.com>