2. Agilidade e XP
TDD
TDD em .Net
TDD na prática
Referências
3. 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
4. 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
6. 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
9. 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
10. 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
11. Integração continua (controle de versão,
servidor de build, testes, inspeção de código
e feedback)
Cliente sempre próximo
Pequenos releases
Programação em pares
Código coletivo
12. Jogos de planejamento (planning poker)
Semanas de 40 horas
Ritmo sustentável
Pequenos releases
13. Jogos de planejamento (planning poker)
Código coletivo
Programação em pares
Refatorar sempre, sem misericórdia
Integração contínua
TDD
14. 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
15. 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
16. 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
17. 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
18. 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
19. 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
20.
21. 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?
22. 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
23. 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
24.
25. 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
26. 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
27. 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
28. TDD veio do Java mas ...
Apoio pela IDE
Apoio dos frameworks
Inúmeros frameworks open-source também
29.
30.
31.
32.
33. 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)