TDD NA PRÁTICADesenvolvimento Orientado a Testes

Rafael Fuchs

agenda

• introdução a TDD• design emergente• tipos de testes• mais sobre TDD• exemplos• dificuldades• acoplamento/coesão• mocks/stubs• ferramentas• revisão• referências

introdução a TDD

• Test Driven Development• Desenvolvimento Orientado a Testes• 1999 – Kent Beck + XP• princípio de test first• 2003 – TDD: by Example• técnica de desenvolvimento• não é sobre escrever testes• mas por que TDD???

TDD

red > green > refactor

adicione código

para teste PASSAR

refatore!

adicione UM teste que FALHE

tipos de teste - escopo

unit testingintegration testing

system testingsystem integration testing

tipos de teste - objetivo

smokeregressãoaceitação

alphabeta

tipos de teste – não funcional

performancecarga

usabilidadesegurança

...

automatizado vs. unitáriounitário• direcionado: testa uma condição específica em um métodos

específico• isolado: o código sendo testado não pode ter dependência

externa• repetível e previsível: deve ser capaz de ser roda várias vezes e

produzir sempre o mesmo resultado• independente: não podemos garantir a ordem dos testes –

seus testes devem funcionar e ter o mesmo comportamento se rodados em qualquer ordem

automatizado• …

TDD

• Escreva um teste que falhe antes de escrever qualquer outro codigo (red)

• Escreve o mínimo de código possível para fazer esse teste passar

• Refatore...• Repita o processo

TDD adicione código para teste

PASSAR

refatore!

adicione UM teste

que FALHE

TDD

• objetivo simples:– programar algo que satisfaça uma condição

• baby steps• primeiro teste: chama algo que não existe• rascunho do seu código

TDD

• design/arquitetura emergente• mais coesão, menos acoplamento• isolamento de erros• modularização• não é solução para todos os problemas do

mundo

red > green > refactor

TDD adicione código

para teste PASSAR

refatore!

adicione UM teste que FALHE

as 3 leis do TDD

1. Você não pode escrever código de produção a menos que ele tenha um teste que falhe.

2. Você não pode escrever mais teste que o suficiente para falhar – erros de compilação são falhas.

3. Você não pode escrever mais código que o suficiente para o código de produção passar em um teste.

(Martin Fowler, 2011)

TDD - vantagens

• melhor entendimento dos requisitos• garantir testes• maior qualidade de código• maior simplicidade• menos código• melhor uso OOP• menos defeitos• gera exemplos de uso• menos debug Página 1/329

TDD - vantagens

• maior confiança• manutenção mais fácil• menor custo de mudança• eliminar dead code/código parasita• evitar erros de regressão• maior cobertura• acaba quando termina• feedback constante

Página 2/329

TDD - vantagens

Página 3/329

TDD - vantagens

Página 4/329

TDD - estudos

• Redução de 40-50% na quantidade de defeitos• 87% - facilitou o entendimentos dos requisitos• 96% - reduziu o tempo gasto com debug• 78% - aumentou a produtividade• 50% - ajuda a diminuir o tempo de desenvolvimento• 92% - ajuda a manter um código de maior qualidade• 79% - promove um design mais simples• 104% - menos acoplamento• 43% - métodos menos complexos• cobertura entre 92% - 98%

Página 5/329

TDD - desvantagens

• testes viciados• falsa sensação de segurança• suporte gerencial / alta administração• mau uso• muita integração externa• curva de aprendizagem• atrapalha linha de pensamento• banco de dados

TDD - dificuldades

onde começar?

o que testar?

quando parar?

CUIDADO!!!

getters/setters

delegação

acesso a sistemas externos(banco, file system, ws, etc)

pode-se garatir qualidade de outra formas

exemplo 01 - soma

Classe com método simples para somar 2 inteiros.

Adicionar um teste

public class TesteSoma extends TestCase {@Testpublic void testSomaUmMaisUm() {

assertEquals(2, Calc.soma(1,1));}

}

FALHA! Não compila!

Escrever código para teste passar

public class Calc {static public int soma(int a, int b) {

return 2;}

}

public class TesteSoma extends TestCase {@Testpublic void testSomaUmMaisUm() {

assertEquals(2, Calc.soma(1,1));}

}

Compila e o teste passa!

Adicionar um teste – código já é simples e claro

public class Calc {static public int soma(int a, int b) {

return 2;}

}

public class TesteSoma extends TestCase {[...]@Testpublic void testSomaDoisMaisTres() {

assertEquals(5, Calc.soma(2,3);}

}

FALHA!

Escrever código para teste passar

public class Calc {static public int soma(int a, int b) {

if (a==2 && b==3) return 5;return 2;

}}

public class TesteSoma extends TestCase {@Testpublic void testSomaUmMaisUm() {

assertEquals(2, Calc.soma(1,1));}@Testpublic void testSomaDoisMaisTres() {

assertEquals(5, Calc.soma(2,3);}

}

Teste passa!

Agora sim: Refatorar!

public class Calc {static public int soma(int a, int b) {

return a + b;}

}

public class TesteSoma extends TestCase {@Testpublic void testSomaUmMaisUm() {

assertEquals(2, Calc.soma(1,1));}@Testpublic void testSomaDoisMaisTres() {

assertEquals(5, Calc.soma(2,3);}

}

Teste continua passando… tudo certo!

exemplo 02 – Crivo de Eratóstenes

Crivo de Eratóstenes: algoritmo para gerar números primos

0-1-2-3-4-5-6-7-8-9-10Em seguida o algoritmo elimina os números 0 e 1 por não serem primos:

2-3-4-5-6-7-8-9-10Começando pelo número 2, elimina-se cada um dos seus múltiplos, com exceção dele próprio (que é primo).

2-3-5-7-9Avançando para o próximo número ainda não eliminado, que é 3, o algoritmo elimina cada um de seus múltiplos com exceção dele próprio.

2-3-5-7O processo é repetido até se alcançar o número máximo informado. No caso do exemplo acima, os passos executados já foram suficientes para identificar todos os primos até 10.

Fonte:http://desenvolvimentoagil.com.br/xp/praticas/tdd/

Iniciamos pelo teste...

E rodamos o teste sem código.Obviamente vai falhar...

Nosso teste:

Escrevemos um código mínimoPara fazer o teste passar.

Código mínimo mesmo.

Adicionamos um teste... Que falha.

E escrevemos código para o teste passar...

Então refatoramos nosso código... Testes e código de produção

Mais um pouco de refatoração, sempre rodando os testes para garantir o bom funcionamento.

Após algumas rodadas de refatoração... O algoritmo completo.

Mais alguns testes – e agora todos devem passar...

design/arquitetura emergente

(evolutivo, orgânico)pequenos pedaços de software

evitar trabalho antecipadoúltimo momento responsável

modelo tradicional: preguiça de mudar mais tarde

mocks e stubs

• simular estado/comportamento• sistemas/bibliotecas externos• banco de dados• stubs: nos preocupamos em testar o estado dos

objetos após a execução do método. Neste caso incluimos os asserts para ver se o método nos levou ao estado que esperamos.

• mocks: testar a interação entre objetos e o comportamento do objeto durante a execução do método. Neste caso, os asserts servem para ver se os métodos se relacionaram como o esperado.

exemplo de jMockit

setup e testando exceção

exemplo de jMockitteste simples

coesão e acoplamento

coesão• responsabilidade unica

uma classe deve ter uma unica responsabilidade • maior modularização e reuso• muitos testes para um metodo/classe

acomplamento• dependência de outras classes• inversão de controle e injeção de dependência• muitos mocks/stubs

ferramentas• testes unitários

– jUnit (http://junit.org/)– xUnit (http://xunit.codeplex.com/)

• mocks– Mockito (https://code.google.com/p/mockito/)– jMockit (https://code.google.com/p/jmockit/)– jMock (http://jmock.org/)– EasyMock (http://easymock.org/)– moq (https://code.google.com/p/moq/)

• cobertura– Cobertura (http://cobertura.github.io/cobertura/)– EMMA (http://emma.sourceforge.net/)

retomando...

• red > green > refactor• tipos de testes• testes automatizados vs. unitários• baby steps• design emergente• mocks/stubs• coesão/acomplamento• ferramentas• cobertura

TDDadicione código

para teste PASSAR

refatore!

adicione UM

teste que FALHE

livros

• Refactoring: Improving the Design of Existing Code (Martin Fowler)http://www.amazon.com/exec/obidos/ASIN/0201485672

• Test Driven Development: By Example (Kent Beck)http://www.amazon.com/exec/obidos/asin/0321146530/

• Extreme Programming Explained: Embrace Change (Kent Beck)http://www.amazon.com/Extreme-Programming-Explained-Embrace-Edition/dp/0321278658/ref=pd_sim_b_3

obrigado!

perguntas?

Rafael Fuchsrafael.fuchs@adp.com@rafaelfuchs