TDD

 Agilidade e XP
 TDD
 TDD em .Net
 TDD na prática
 Referências

 Indivíduos e interação mais que processos e
ferramentas
 Software funcionando mais que
documentação abrangente
 Colaboração com o cliente mais que
negociação de contratos
 Responder a mudanças mais que seguir um
plano

 Kent Beck (XP, TDD)
 Mike Beedle
 Arie van Bennekum
 Alistair Cockburn
 Ward Cunningham
 Martin Fowler (Patterns, Refactoring)
 James Grenning
 Jim Highsmith
 Andrew Hunt
 Ron Jeffries
 Jon Kern
 Brian Marick
 Robert Martin (Clean Code, Agile)
 Steve Mellor
 Ken Schwaber (Scrum)
 Jeff Sutherland
 Dave Thomas

 Custo

 Tempo

 Qualidade

 Escopo*

 Simples, leve, rápido e divertido

 São as práticas que mais agradam os
programadores e que causaram maior
“barulho” nas empresas e na comunidade

 O primeiro livro de XP é o livro do Kent Beck

 Comunicação
 Simplicidade
 Feedback
 Respeito
 Coragem

 Espaço aberto (todos juntos com o cliente, sem
baias, war rooms, flipcharts, lousas e etc)
 Programação em pares (nivelamento de
conhecimento técnico e do projeto)
 Movimente as pessoas
 Cliente sempre próximo
 Código coletivo
 Metáfora do sistema
 TDD
 Padrões de código

 TDD (desenvolvimento guiado a testes)
 Modelagem simples (KISS - Keep it simple,
stupid!)
 Ser simplista não é não pensar no futuro mas
não faça aquilo que não é necessário
 Refatorar sempre, sem misericórdia
 Pequenos releases
 Metáfora do sistema
 Padrões de código

 Integração continua (controle de versão,
servidor de build, testes, inspeção de código
e feedback)
 Cliente sempre próximo
 Programação em pares

 Jogos de planejamento (planning poker)
 Semanas de 40 horas
 Ritmo sustentável

 Jogos de planejamento (planning poker)
 Programação em pares
 Refatorar sempre, sem misericórdia
 Integração contínua
 TDD

 Desenvolvimento guiado por testes
 O primeiro livro sobre o assunto também foi
escrito pelo Kent Beck
 A prática mais viciante e uma das mais
importantes do XP
 Fácil de explicar mas difícil de aprender (dói)
e leva tempo, mas de retorno garantido

 Código mais claro
 Testes são documentações executáveis
 Testes garantem funcionalidades do domínio
do problema
 Se algum teste parou de rodar, sabemos que
algo deu errado
 Independência de uma camada gráfica para
testar as camadas mais baixas(negócios, db,
etc)
 Economia de tempo e dinheiro em
manutenção

 Você deve criar uma grande quantidade de
testes
 Nenhum código vai para produção sem ter
um teste correspondente
 O teste SEMPRE é escrito antes
 Rode seus testes com frequencia
 O teste te diz que código de produção você
deve escrever
 Primeiro eu codifico o teste, depois codifico o
código de produção

 Não escreva código de produção até que você
tenha escrito um teste unitário falho
 Não escreva mais do que um teste que já seja
suficiente para falhar, não compilar é uma
falha
 Não escreva no código de produção mais do
que o suficiente para passar no seu teste
falho

 Testar é fácil, se está difícil escrever um teste
o código está mal feito
 TDD nos leva a usar boas práticas de
modelagem e arquitetura
 TDD nos leva a um baixo acoplamento
 TDD nos leva a desenvolver para interfaces
 Refatore sem medo, afinal você está coberto
pelos testes

 Sempre que encontrar um bug escreva um
teste que o exponha
 Os testes devem evoluir, assim como o
código evolui
 Testes que não são atualizados são apenas
código legado
 Aprender a escrever testes é também um
processo gradativo
 Crie testes as Exceptions

 Reescrever o código de forma que fique mais
fácil o seu entendimento e por consequência
a sua manutenção
 Ninguém faz nada perfeito da primeira vez
 Na verdade não existe código perfeito, ele
sempre tem alguma coisa que pode melhorar
 Será que eu não introduzi bugs quando
refatorei?

 Tanto o código de teste quanto o código de
produção devem ser constantemente
refatorados
 Durante o processo do TDD o código de
produção é revisto várias vezes
 Criar testes me garante que posso refatorar a
vontade, pois os testes vão me avisar caso eu
insira algum bug

 Classes com nomes que sejam substantivos
 Métodos com nomes que sejam verbos
 Propriedades com nomes que sejam
substantivos
 Variáveis com nomes que sejam substantivos
 Nomes que tenham significado de negócio
 Convenções de nomes
 Evite comentários no código, se você precisa
comentar é porque seu código não está claro
então reescreva

 Apenas um Assert por teste
 Um conceito por teste
 F.I.R.S.T.
◦ Fast – rápidos de rodar
◦ Independent – independentes entre si
◦ Repeatable – fáceis de executar a qualquer
momento
◦ Self-Validating – fácil de descobrir se deu certo ou
não
◦ Timely – teste deve ser feito pouco antes do código
de produção

 São objetos fake que permitem que o teste
seja isolado em apenas uma classe
 Serve para remover dependências que o teste
pode ter como, banco de dados, web
services, outras classes, entre outros

 Une classes e componentes em tempo de
execução
 Permite que quando estivermos rodando os
testes apontemos para classes stubs e
quando o código for executado em produção
volte para as classes originais
 Não é indispensável, mas é útil

 TDD veio do Java mas ...

 Apoio pela IDE
 Apoio dos frameworks
 Inúmeros frameworks open-source também

 Criação de testes unitários
 Criação de stubs
 Criação de classes e métodos
automatizadamente
 Ambiente para execução dos testes unitários
(Test Explorer)
 Ferramenta de análise de cobertura de código
(Code Coverage)
 Ferramenta de análise da complexidade do
código (Code Metrics)
 Ferramenta para teste de desempenho e carga
(Performance Wizard)

 Robert C. Martin
(Uncle Bob)
 2002

(Uncle Bob)
 2008

(Uncle Bob)
 2011

 Jimmy Nilsson
 2006

 Martin Fowler
 2009

 Michael Feathers
 2004

 James Bender
 Jeff McWherter
 2011

TDD

Mais conteúdo relacionado

Mais procurados

Destaque

Semelhante a TDD

TDD