32

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

Embed Size (px)

Citation preview

Page 1: Test Driven Development Eloi Rocha Neto, 06/10/2007
Page 2: Test Driven Development Eloi Rocha Neto, 06/10/2007

Test Driven DevelopmentTest Driven DevelopmentEloi Rocha Neto, 06/10/2007

Page 3: Test Driven Development Eloi Rocha Neto, 06/10/2007

3

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?

Page 4: Test Driven Development Eloi Rocha Neto, 06/10/2007

4

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?

Page 5: Test Driven Development Eloi Rocha Neto, 06/10/2007

5

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!

Page 6: Test Driven Development Eloi Rocha Neto, 06/10/2007

6

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

Page 7: Test Driven Development Eloi Rocha Neto, 06/10/2007

7

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

Page 8: Test Driven Development Eloi Rocha Neto, 06/10/2007

8

Introdução• Existem vários tipos de testes

– Testes de Unidade– Testes de Regressão– Testes de Integração– Testes Funcionais

• Foco: Testes de Unidade

Page 9: Test Driven Development Eloi Rocha Neto, 06/10/2007

9

Introdução• Do que precisamos para começar?

– Um ferramenta que nos auxilie a desenvolver e testar nossos testes de unidade

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

10

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

Page 11: Test Driven Development Eloi Rocha Neto, 06/10/2007

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

Page 12: Test Driven Development Eloi Rocha Neto, 06/10/2007

12

JUnit• Seja a seguinte classe:public class Calculadora {

public int somar(int a,int b) {return a + b;

}}

Page 13: Test Driven Development Eloi Rocha Neto, 06/10/2007

13

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

}

Page 14: Test Driven Development Eloi Rocha Neto, 06/10/2007

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

Page 15: Test Driven Development Eloi Rocha Neto, 06/10/2007

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(); }

...

Page 16: Test Driven Development Eloi Rocha Neto, 06/10/2007

16

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!

Page 17: Test Driven Development Eloi Rocha Neto, 06/10/2007

17

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

Page 18: Test Driven Development Eloi Rocha Neto, 06/10/2007

18

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)

Page 19: Test Driven Development Eloi Rocha Neto, 06/10/2007

19

JUnit• Usando linha de comando:

– java -cp junit-4.4.jar;. junit.swingui.Test MeuTest

Page 20: Test Driven Development Eloi Rocha Neto, 06/10/2007

20

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?!?

Page 21: Test Driven Development Eloi Rocha Neto, 06/10/2007

21

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.

Page 22: Test Driven Development Eloi Rocha Neto, 06/10/2007

22

TDD• Mantra do

TDD:– Escrever um

teste

– Codificar o mínimo o possível para o teste passar

– Refatorar

Page 23: Test Driven Development Eloi Rocha Neto, 06/10/2007

23

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.

Page 24: Test Driven Development Eloi Rocha Neto, 06/10/2007

24

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

Page 25: Test Driven Development Eloi Rocha Neto, 06/10/2007

25

TDD• Quando escrevemos um teste antes de

codificar estamos pensando em:– design– teste– documentação

Page 26: Test Driven Development Eloi Rocha Neto, 06/10/2007

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.

Page 27: Test Driven Development Eloi Rocha Neto, 06/10/2007

27

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.

Page 28: Test Driven Development Eloi Rocha Neto, 06/10/2007

28

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

Page 29: Test Driven Development Eloi Rocha Neto, 06/10/2007

29

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.

Page 30: Test Driven Development Eloi Rocha Neto, 06/10/2007

30

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.

Page 31: Test Driven Development Eloi Rocha Neto, 06/10/2007

31

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

Page 32: Test Driven Development Eloi Rocha Neto, 06/10/2007

<[email protected]>

Muito obrigado pela atenção!