TDDA Verdadeira Face do Teste

Aislan Fernandes@aislanfp

aislanfp@gmail.com

RoteiroContextosConceitosFerramentasTécnicasDemonstração

ReferênciasKOSKELA, Lasse. Test Driven:

Pratictal TDD and Acceptance TDD for Java Developers. Manning. Greenwich, 2008.

FOWLER, Martin. Refactoring: Improving the Design of Existing Code. Addison-Wesley. 1999.

BECK, Kent. Programação Extrema (XP) Explicada – Acolha as mudanças. Porto Alegre: Bookman, 2004.

Projeto

Custo

Tempo

Qualidade

Escopo

Contexto Maior (Organização)

Software Mudanças

Engenharia de

Software

Contexto Menor (Equipe)

O custo da mudança não é exponencial mas achatado

Não há aquele código difícil de modificar , acompanhado de medo e da falta de testes para verificar se houve efeito colateral.

TDD é um ingrediente chave

* BECK, 2004; **LARMAN, Craig.

Metodologias Ágeis

Iterativo e Incremental

XP Scrum PU**

“Mudança é uma constante, o problema é falta de habilidade”*

ConceitoTDD não é desenvolvimento com testes!

Regra 10 de Myers

Quanto mais cedo defeito descoberto

menor custo de correção

ConceitoTDD = fazer certo TDD = Test-code-refactorTDD = Red-green-refactorTDD = Test Driven DevelopmentTDD = Test Driven DesignTDD = Test-First Programming

* Erich Gamma

Acceptance TDD (ATDD) = fazer a coisa certa ≈ BDD

“Infectado por Testes”* = não codificar sem teste antes

100%

Objetivos* BenefíciosEncorajar um bom designProduzir código testávelEvitar engenharia excessiva ou

pesadaEvitar código mal escrito, difícil de

entender e de mudarCortar o tempo em tarefas não

produtivas:DebuggingResolvendo bugsEntendendo código ilegível

Testes

Revelar falhas

Mostrar que faz o que deve ser

feito

Revelar design

Especificar em exemplos

* KOSKELA, 2008

Programar e testar ao mesmo tempo é mais rápido do que apenas programar!

FuncionamentoCiclo TDD Escreva o teste, e somente então escreva o

código para passar no teste. Por fim, transforme o design atual num melhor (refactor).

Repetição dos ciclos TDD = design evolucionárioQuando parar?Ponto de satisfação ≈ conhecimento de padrões de projeto

Test

Code

Refactor

Test

Code

Refactor

* BECK, 2004

“Os testes me dão a chance de pensar sobre o que eu quero independentemente da

implementação.”*

* KOSKELA, 2008

Design

evolucionário

Design em papel

no come

ço

Design EvolucionárioFeedback imediato design somente evolui

quando efetiva e objetivamente o usamos, escrevendo o teste antes*Escrever teste = decidir sobre design

Focado no presente menos custosoUso de code coverage gordura?Priorizado em histórias

“Quando você acrescenta mais ao projeto hoje, você aumenta a sobrecarga do sistema. Há

mais coisas para testar, entender e explicar”**“Os problemas de hoje já são

suficientes”**** BECK, 2004

* KOSKELA, 2008

Design EvolucionárioTestar + Refatorar Escrever testes antes

promove um certo nível de testabilidade, porém é preciso estar consciente de não construir um que funciona agora mas pode explodir em breve *

Design Testável Prefira composição em vez de herança

Mais código Melhor testabilidade, flexibilidade e manutenção

Procure isolar e injetar dependências

Mais código Melhor testabilidade e manutenção

RefactoringTécnica para reestruturar um código

existente, alterando sua estrutura interna sem alterar seu comportamento externo*

DisciplinadoNão prevemos e nem nos preparamos para

problemas de design antes de ter um em mãos, evitando criar mais problemas

PadronizadoRemoção de código duplicadoProblemas específicos

* FOWLER, 1999

HerdarDelegar

HerançaComposição

GRASP

GoF

Ferramentas

Análise EstáticaEMMA Code

CoveragePMD Duplicação e

padrões

Frameworks EasyMock JUnitDBUnit

Integração ContínuaHudsonTeamCityApache Continuum

EasyMockMá Prática classes

vazias como mocksFoco preocupação

com teste e não com ambiente

Problemas erros de compilação nos testes quando mudam as interfaces

Mocks

Stubs

ITranslator mockTranslator = createMock(ITranslator.class);

Greeting greeting = new Greeting(mockTranslator);

expect(mockTranslator.translate("English", "Hindi",

"Hello")).andReturn("Namaste");replay(mockTranslator);

assertEquals("Namaste Paulo", greeting.sayHello("Hindi", "Paulo"));

verify(mockTranslator);

Integração ContínuaMédio e longo prazo repositório de testes

difíceis de gerenciar individualmente Não é possível executar todos os testesExecutar suite de testes a cada pequena

mudança permite um feedback imediato

Implementação

Decomposição de Requisito* criar uma lista de testes em vez de tarefas Foco no que é necessário e não no que

poderia ser feitoProgramação por Intenção* escrever teste

sem código algum, como se o código existisse!Foco no que necessitamos e não no que temos

Decomposição de

requisito

Programação por

intenção

* KOSKELA, 2008

Teste é algo um pouco mais concreto, mais executável, mais exemplificativo do que o requisito

ImplementaçãoQual teste selecionar?Estratégias*

“Primeiro pelos Detalhes” X “Primeiro pelo Todo”

Incerto X FamiliarMaior Valor X Menor Valor“Caminho Feliz” X Situações de Erro

Não há fórmula mágica!

* KOSKELA, 2008

Faking

Triangulação

Implementação

ImplementaçãoEtapas*

FakingTriangulaçãoImplementação Óbvia

FakingPasso mais fácil para o

teste passar (red green)

Ter um momento mais concreto

Comece retornando valores hardcoding

* KOSKELA, 2008

Implementação

Implementação ÓbviaApós triangulação, o trabalho restante vai

parecer óbvio ou bem mais natural

Triangulação transformar código fake em código de produçãoOs testes levam à

solução corretaTriangular = variar

testes com novos valores

DemonstraçãoX LTDA

Mostra 1 em 1 semana

Mudança!

Aceita e não entrega a 3.

História 3

História 2

Histó

ria 1

DemonstraçãoX LTDA

TDD história 1

Mudança refactoring

Maior valor ficou!

Considerações FinaisBoas práticas

Qualidade do teste atômico e enxutoGranularidade do código = teste

Outras aplicaçõesCódigo legadoInterface gráfica

DificuldadesTrabalho em equipe (coesão alta)Cultura (pré-conceito e atitude)Conhecimento de padrões

Curso de TDD