tdd na prática
DESCRIPTION
Nesta palestra iremos abordar os principais conceitos relacionados ao Desenvolvimento Orientado a Testes (TDD - Test Driven Development) e usaremos exemplos práticos para ilustrar essa poderosa técnica de desenvolvimento de software.TRANSCRIPT
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