Palestrante

Thiago Faria de Andrade

Programador há mais de 15 anos

9 anos de experiência com Java

Bacharel em Sistemas de Informação

Certificado como programador Java pela Sun

Consultor, arquiteto, desenvolvedor, escritor e instrutor Java

Diretor/Proprietário da AlgaWorks

Diretor de Tecnologia da Boobow

AgendaO que é TDD?

Quem inventou?

Espiral da morte

Benefícios

Padrões do TDD

Red Bar Patterns

Testing Patterns

Green Bar Patterns

Padrões xUnit

Refatoração

Dominando TDD

Como aprender TDD

O que é TDD?

Técnica de desenvolvimento de software

Testes unitários automatizados

Test-first programming (da XP)

Processo formado por pequenas iterações

O que é TDD?

Já sei, é um método para testar software!

O que é TDD?

Não é um método para testar software

É um método para construir software

O que é TDD?

Através do processo “vermelho-verde-refatorar”

Com “código limpo que funciona” (Ron Jefrries)

Quem inventou?

Não sei…

Mas um criador de cabras que redescobriu TDD.

@kentbeck

Espiral da morte “sem tempo para testar”

Benefícios

Testes unitários sempre atualizados

Design guiado pelos testes

Aumento de confiança

Qualidade de código

Baixo acoplamento

Alta coesão

Código limpo

Testes são especificações

Padrões do TDD

Crie uma lista de testes

• Faça um brainstorm

• Identifique e anote todos os testes que você precisará escrever

• Faça isso para uma mesma classe ou método a ser testado

• Durante o desenvolvimento, você pode adicionar novos testes a essa lista

Padrões do TDD

Crie testes isolados uns dos outros

• Um teste não pode depender de outro

• Deve ser possível executar um teste isoladamente

Padrões do TDD

Teste primeiro

• Escreva o teste antes do código que é para ser testado

• É uma oportunidade para pensar no design das classes

• Uma forma de controlar o escopo do que será implementado

Padrões do TDD

Assertiva primeiro

• Pense primeiro no sucesso do teste

• Depois pense se vai precisar de um método, de uma classe, os nomes dos parâmetros, etc

Padrões do TDD

Como assim?

Padrões do TDD

Como assim?

Padrões do TDD

Dados para teste

• Não use números mágicos

• Evite passar o mesmo valor para diferentes parâmetros

• Use dados do mundo real

Padrões do TDD

Use dados evidentes

• Testes são para pessoas, não para computadores

• Escreva na assertiva uma expressão não só que representa o valor final esperado, mas o que ele significa

Padrões do TDD

Use dados evidentes

Padrões do TDD

Ao invés de…

Red Bar Patterns

Quando e onde escrever os testes?

Quando parar?

Red Bar Patterns

Um passo de cada vez

Qual o próximo teste?

• O que você está confiante e vai lhe ensinar algo

• Para cada pessoa a resposta é diferente

• Cada teste deve representar um passo em direção ao objetivo final

Red Bar Patterns

Primeiro teste

• Não comece pelo mais completo

• Comece pelo menor

• Comece pelo mais simples

Red Bar Patterns

Explicação usando testes

• Não dá para forçar ninguém a mudar a forma de trabalhar

• Peça explicações em termos de testes

• Explique em termos de testes

Red Bar Patterns

Testes de estudo

Podemos escrever testes para componentes de terceiros?

•Apenas para estudar ou documentar o uso

•Não teste todos os recursos do componente terceiro

Red Bar Patterns

Novo teste

O que fazer quando surgir uma discussão?

• Adicione um novo item na lista de testes

• Volte ao assunto principal

Red Bar Patterns

Teste de regressão

• Se um defeito for encontrado, escreva um pequeno teste que falha, execute e depois implemente a correção

• Para escrever o teste, pense em como você teria feito se fosse no passado

Red Bar Patterns

Pausa

• Quando estiver cansado, dê uma pausa

• Beba água, descanse, tenha outros compromissos diferentes e saia de férias

Red Bar Patterns

Comece de novo

• Se estiver perdido, jogue tudo fora e comece de novo

Testing Patterns

Técnicas mais detalhadas de como escrever testes

Hum… legal!

Testing Patterns

Testes menores

• Se o teste ficou grande demais, deixe-o e escreva um pequeno que representa parte dele

• O ciclo “verde-vermelho-refatorar” deve ser rápido

Testing Patterns

Objetos dublês (mock)

Como testar objetos que dependem de recursos externos, caros e complicados?

•Crie uma versão falsa deles que retornam constantes

•Existem diversas ferramentas para ajudar a fazer isso (eu uso o Mockito)

Testing Patterns

Teste de falhas

Como testar falhas difíceis de reproduzir?

•Falsifique o objeto

•Construa uma nova classe que lance uma exceção

Testing Patterns

Teste quebrado

• Se está desenvolvendo um projeto sozinho, deixe sempre um teste em vermelho

• Isso facilita a continuação no próximo dia

Testing Patterns

Check-in limpo

• Se trabalha em equipe, só faça commit quando os testes estiverem verdes

• Execute todos os testes antes de submeter o código

Green Bar Patterns

Padrões para fazer o teste passar

Como fazer um teste vermelho ficar verde rapidamente?

Green Bar Patterns

Falsifique até construir realmente

• Implemente um código falso que retorna uma constante (só para fazer o teste passar)

• Ter algo rodando é melhor que não ter

• Isso gera um bom efeito psicológico

Green Bar Patterns

Triangulação

• Abstraia métodos quando tiver dois ou mais testes

• Quando fazemos isso, somos forçados a implementar algo que realmente funciona (sem falsificação)

Green Bar Patterns

Implementação óbvia

Como implementar operações simples?

• Apenas codifique a solução diretamente

• Se sabe o que precisa digitar, então faça

• Prepare-se para voltar atrás e dar um passo menor se suas mão não conseguirem acompanhar seu cérebro

Green Bar Patterns

Coleções

• Para implementar operações sobre coleções, implemente primeiro sem coleções

• Depois faça funcionar com coleções

Padrões xUnit

xUnit é o nome genérico para ferramentas de testes unitários

Vamos conhecer alguns padrões para usar ferramentas da família xUnit

Padrões xUnit

Asserções

• Escreva expressões booleanas que automatizam o julgamento sobre quando o código funciona

• Deve ser true se estiver ok e false quando houver algum problema

• Seja específico na asserção

• Inclua mensagens informativas na asserção

Padrões xUnit

Construção

Como criar objetos comuns a vários testes?

• Converta as variáveis locais dos testes em variáveis de instância

• Implemente o método setUp() e inicialize as variáveis

Padrões xUnit

Liberação de recursos

Como liberar recursos externos após um teste?

• Implemente o método tearDown() e libere lá

• O teste deve deixar o mundo exatamente como ele estava antes

Padrões xUnit

Método de teste

• O nome do método pode começar com “test”, “deve”, “should” ou nada disso

• O nome do método deve comunicar o que está sendo testado

• O código de teste deve ser curto e fácil de entender

Padrões xUnit

Teste de exceção

Como testar exceções esperadas?

• Capture e ignore a exceção e chame fail() se não houver exceção

• Ou use algum recurso específico do framework

Refatoração

Refatorar é melhorar o design do sistema sem alterar o comportamento

• Como mudar o design do sistema radicalmente ou em pequenos passos?

• Ao refatorar, os testes devem continuar verdes

• Refatoramos para melhorar legibilidade, facilitar manutenção e melhorar performance

Refatoração

Reconcilie diferenças

• Duas partes de códigos iguais podem ser eliminadas

• Dois loops similares, ao fazerem eles idênticos, podem ser fundidos em um só

• Duas condições similares, ao fazerem idênticas, uma pode ser eliminada

• Dois métodos ou classes similares, ao fazerem idênticos, um pode ser eliminado

Refatoração

Isole mudanças

• Se precisar alterar uma parte de um método que possui várias outras partes, isole primeiro o que precisa ser alterado com refatoração

• Extrair métodos é a forma mais comum de fazer isso

Refatoração

Migre dados

Como mudar de uma estrutura de dados para outra?

• Crie uma nova variável e duplique os dados

• Atribua a nova variável em todos os lugares

• Use a nova variável em todos os lugares

• Apague a variável antiga

• Mantenha os testes sempre verdes entre os passos

Refatoração

Extraia métodos

Como fazer um método longo e complicado fácil de ser lido?

•Encontre uma parte do código que faça sentido ter seu próprio método (blocos em loops e caminhos de condições são candidatos)

•Deixe o teste sempre verde durante as mudanças

Refatoração

Elimine métodos

Como simplificar o código quando ele parece muito disperso e sem sentido?

•Substitua a chamada do método pelo código do método

•Entenda melhor o código e depois repense sobre a melhor forma de organizá-lo

Refatoração

Extraia interfaces

Como criar uma segunda implementação de operações em Java?

•Crie uma interface que especifica os métodos compartilhados com o nome da classe existente

•Mude o nome da classe existente para algo que faça sentido

•Adicione os métodos necessários na interface

•Cuidado ao nomear as classes e a interface (dê nomes que realmente fazem sentido)

Refatoração

Mover métodos

Como mover métodos para outros lugares sem precisar modificar quem os chamam?

•Crie um novo método e mova o conteúdo do método antigo para dentro do novo método

•Faça uma chamada ao novo método de dentro do método antigo

Refatoração

Objetos como métodos

Como representar um método complicado que requer muitos parâmetros e variáveis locais?

•Crie uma classe que recebe os mesmos parâmetros do método

•Torne as variáveis locais do método em variáveis de instância da nova classe

•Crie um método run() que execute o mesmo código do método antigo

•No método antigo, instancie um objeto da nova classe e chame run()

Refatoração

Parâmetro de método para parâmetro de construtor

Se você passa os mesmos parâmetros para vários métodos diferentes do mesmo objeto:

•Crie um construtor que recebe os mesmos parâmetros

•Adicione as variáveis de instância na classe com os mesmos nomes dos parâmetros e inicialize-as no construtor

•Mude todas as referências às variáveis para incluir “this.variavel”

Dominando TDD

Perguntas que surgem ao iniciar com TDD.

Dominando TDD

Qual o tamanho ideal dos passos?

• Não existe uma regra

• Mas a tendência é que sejam passos pequenos

• Quando sentir confortável, você poderá dar passos um pouco maiores

• Ferramentas ajudam a pular etapas na fase de refatoração

Dominando TDD

O que você precisa testar?

• Você encontrará essa resposta praticando

• Teste condições, loops, operações, polimorfismo

• Teste apenas códigos que você escreve

Dominando TDD

Como você sabe se tem bons testes?

Alguns atributos que sugerem testes ruins:

• Código de configuração longo ou duplicado

• Testes demorados para executar

• Testes frágeis (que dependem do resultado de outros)

Dominando TDD

Quando você deve excluir um teste?

• É bom ter muitos testes

• Mas se dois testes são redundantes

• Se excluir um diminuirá sua confiança, é melhor deixar assim

• Se os dois testes seguem o mesmo fluxo mas comunicam cenários diferentes, deixe assim

• Se ambos os testes comunicam a mesma coisa e a exclusão de um deles não diminui sua confiança, então exclua um

Dominando TDD

Como migrar um projeto existente para usar TDD?

• O maior problema é que códigos escritos sem pensar nos testes normalmente são difíceis de testar

• Mudanças no código são perigosas porque não existem testes para garantir o funcionamento

• Se tiver partes do sistema que precisam ser simplificadas mas não precisam de mudança no momento, não faça nada

• Quando precisar modificar um método, implemente os testes antes

• Faça testes em nível de aplicação para garantir um certo nível de confiança

Como aprender TDD

Leia livros

Como aprender TDD

Assista vídeos na internet de pessoas usando TDD

Como aprender TDD

Estude códigos de projetos que usam TDD

Como aprender TDD

Pratique muito

Perguntas?

Thiago Faria de Andrade

thiago.faria@algaworks.comTwitter: @ThiagoFAndrade

Obrigado!www.algaworks.com

Twitter: @algaworks