O documento apresenta uma agenda para um treinamento sobre Test-Driven Development (TDD). A agenda inclui introduções, um exercício de coding dojo, explicações sobre as três leis e o ciclo de TDD, refatoração, princípios SOLID e a Lei de Demeter, além de uma sessão sobre ferramentas e frameworks.
2. ● Apresentações e Expectativas
● Coding Dojo
● Era uma vez...
● Introdução ao TDD
● As três Leis e Ciclo de TDD
● Refatoração, Princípios SOLID e Lei de Demeter
● Coding Dojo
● Tech Talk - Ferramentas e Frameworks
Agenda
8. Coding Dojo
Dinâmica:
● Pair Programming
● Papéis
○ Sparring (Piloto)
○ Co-Sparring (Co-piloto)
○ Advisors (Conselheiros)
● Rodadas de X minutos
● Foco no COMO e não na solução
10. Coding Dojo
Dojo: Lista de Supermercado
Com base em uma lista de compra qualquer e um caminho que você
pode fazer em um supermercado de forma que você irá do primeiro ao
último corredor (ver imagem a seguir) sem precisar voltar em lugares
que você já passou.
FONTE: http://blog.billcode.com.br/2011/09/sugestao-para-primeiro-coding-dojo.html
11. Coding Dojo
Dojo: Lista de Supermercado
FONTE: http://blog.billcode.com.br/2011/09/sugestao-para-primeiro-coding-dojo.html
12. Coding Dojo
Dojo: Lista de Supermercado
Problema: Imagine uma situação real, onde você vai no supermercado e faz
uma pequena lista: - desodorante (corredor 5 – posição 3); alho (corredor 1 –
posição 9); shampoo (corredor 5 – posição 2); suco (corredor 1 – posição 1);
ovo (corredor 1 – posição 8); iogurte (corredor 1 – posição 7); escova dental
(corredor 4 – posição 7)
Resultado esperado: 1) suco; 2) iogurte; 3) ovo; 4) alho; 5) escova dental; 6)
shampoo; 7) desodorante.
FONTE: http://blog.billcode.com.br/2011/09/sugestao-para-primeiro-coding-dojo.html
14. Título em Arial Bold 24 pontos
Subtítulo em Arial Bold 15 pontos ed vulputate fermentum
Test-Driven Development - TDD
Era uma vez...
15. ● Num projeto “não tão tão distante”...
● Uma equipe “fanfarrona” que decidiu...
● TESTES? → “Quick and Dirty”
● Cobrindo o código de produção, bastaria.
● De versão em versão, estimativas aumentaram...
● ATRASOS? → Culpa dos testes...
● A cada deploy, subia aquele “mal cheiro”
Era uma vez...
16. - Moral da história -
Código de teste é tão importante quanto o de produção.
Era uma vez...
18. Introdução ao TDD
● O que é “testar”?
● Conceitos - Tipos de testes
○ Unidade
○ Integração
○ Stress
○ Carga
○ Performance
○ Outros (Regressão, Mock, Stubs)
20. O que é TDD?
● O que não é?
● Origem do nome
● Extreme Programming
● Princípios:
○ DRY - “Don’t Repeat Yourself”
○ KISS - “Keep It Simple Stupid”
○ YAGNI - “You Ain´t Gonna Need it”
“Code for Tomorrow, design for today.”
22. ● Testes são um meio para um fim
a. Ter CONFIANÇA no código produzido
● Com ele, você vai de:
a. Hesitante → Rápido aprendizado
b. Pouco comunicativo → Melhor comunicação
c. Evitar feedback → Aumentar feedbacks
d. Mal humorado → Confiante no código (que funciona)
Pra quem o TDD é indicado?
24. ● Motivações (óbvias para nós, devs)
○ Eliminar MEDO e INCERTEZA
● Outras nem tão óbvias
○ Código mais limpo
○ Melhor design
○ Maior flexibilidade
○ Feedback rápido
Motivação ao TDD
25. Para o TDD fazer parte do seu dia-a-dia, e perdurar.
Seus testes precisam ser FIRST:
● Fast
● Independent
● Repeatable
● Self-Validating
● Timely
Introdução ao TDD
26. Como saber se escrevi “bons” testes?
● Setup longo?
● Setup duplicado?
● Testes demoram a rodar?
● Testes frágeis?
Introdução ao TDD
28. ● Redução de bugs → menor custo
● Menor stress
● Foco
● Melhor relacionamento da equipe
● Sem builds quebrados
● Confiança interna e externa
● Nova versão → mais funcionalidades (e menos bugs)
Porque o TDD funciona?
29. “Não teste o código que não é seu" (Biblioteca de terceiros)
"Se você não testa seu código, ele já se tornou legado"
"Não re-escreva nada que você não tenha um teste"
Algumas citações sobre TDD
31. As três Leis do TDD
1. Não escreverás código de produção até que tenhas escrito
um teste que esteja falhando.
2. Não escreverás mais que o suficiente para falhar um teste
de unidade, e não compilar é falhar.
3. Não escreverás mais código que o suficiente para passar o
teste falho.
32. Ciclo Red-Green-Refactor
RED: Escreva um teste que não funcione, nem mesmo compile
(teste falhando)
Ao escrever o teste falho, você decidiu:
● De “quem” é a funcionalidade?
● Qual nomenclatura (DSL)?
● Qual a resposta certa?
● Quais outros cenários/testes
relacionados?
33. Ciclo Red-Green-Refactor
GREEN: Faça o teste passar da forma mais simples e rápida
possível
● Objetivo → “barra verde” a qualquer custo
● Foco na resolução do problema/cenário
● Feedback rápido
34. Ciclo Red-Green-Refactor
REFACTOR: Hora de pagar o débito técnico. Código limpo!
(produção e testes)
● Refatoração sem MEDO
● Princípios SOLID
● Lei de Demeter
● Design Patterns
37. Refatoração
Refactoring: “A change made to the internal structure of
software to make it easier to understand and cheaper to
modify without changing its observable behavior.” [FOWLER,
1999]
Refactor: “To restructure software by applying a series of
refactorings without changing its observable behavior.”
[FOWLER, 1999]
38. Por que Refatorar?
Principais motivos:
● Pagar o débito técnico
○ “Code for Tomorrow, design for today.”
● Ajudar a encontrar “bugs”
● Tornar futuras mudanças “baratas”
● Legibilidade
● Legibilidade
● Legibilidade
39. Refatoração
Algumas técnicas conhecidas:
● Extract Method
● Remove temp with query
● Move method/field
● Extract class
● Hide delegate (Lei de Demeter)
● Remove middle man (Oposto de hide delegate)
● Remove data value with object
● ...
42. Refatoração
Padrões de Projeto no TDD:
Padrão Escrita do Teste Refatoração
Command x
Value Object x
Null Object x
Template Method x
Factory Method x x
Imposter x x
Composite x x
Collecting Parameter x x
43. Refatoração
Quando posso apagar meus testes?
● Quando ele não ajuda a aumentar sua confiança
● Quando não ajuda a melhorar a comunicação
48. Open/Closed Principle
Quando um simples mudança resulta numa sequência de
outras, temos um programa:
● Frágil
● Rigido
● Imprevisível
● Sem re-uso
49. Open/Closed Principle
“Entidades de Software (classes, módulos, funções, etc.)
devem ser abertas para extensão, mas fechadas para
alteração”
50. Open/Closed Principle
Quando os requisitos mudam, estende-se um comportamento
adicionando código novo, ao invés de mudar código antigo que
funciona.
Como? → Abstração
51. Liskov Substitution Principle
● “Design by Contract”
● Violações (Code smells)
○ Run-Time Type Information (RTTI)
○ Cuidado com as relações “É um”
● O princípio é sobre: Comportamento
○ Pré-condições
○ Pós-condições
61. Lei de Demeter
Um método de um objeto deveria invocar somente métodos
dos seguintes tipos de objetos:
● Dele próprio
● Dos pâmetros dele
● De qualquer objeto criado ou instanciado
● Seus objetos/componentes diretos (1 nível)
62. Lei de Demeter
Onde e quando aplicar a Lei de Demeter?
● Chamadas de métodos (normalmente “get”) encadeadas
● Onde há muitos objetos temporários
● Ao importar muitas classes
○ Exemplo: import java.awt.*;
● Design Patterns (GoF)
66. Referências
● BECK, Kent. Test Driven Development: By Example, Addison-Wesley, 2002.
● EVANS, Benjamin J.; VERBURG, Martijn. The Well Grounded Java
Developer, Manning, 2013.
● FOWLER, Martin. Refactoring: Improving the Design of Existing Code,
Addison-Wesley, 1999.
● FREEMAN, Steve; PRYCE, Nat. Growing Object-Oriented Software Guided by
Tests, Addison-Wesley, 2009.
● HUNT, Andrew; THOMAS, David. The Pragmatic Programmer, Addison-
Wesley, 1999.
● MARTIN, Robert C. Clean Code - A Handbook of Agile Software
Craftsmanship, Prentice Hall, 2009.
● McCONNELL, Steve. Code Complete - A Practical Handbook of Software
Construction, 2nd Edition, Microsoft Press, 2004.
● MYERS, Glenford J. The Art of Software Testing, John Wiley & Sons, Inc.,
2004.