Treinamento TDD - Atech
-
Upload
cesarcneto -
Category
Technology
-
view
434 -
download
1
description
Transcript of Treinamento TDD - Atech
Test-Driven Development - TDD
César Caetano Neto - [email protected]
● 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
Test-Driven Development - TDD
Apresentações e Expectativas
Apresentações e Expectativas
● Nome
● Biografia profissional
● Expectativas...
Testes: Todo mundo sabe, mas nem todos fazem (direito).
Test-Driven Development - TDD
Coding Dojo
Coding Dojo
Você se considera um bom programador?
● Em geral, programadores NÃO TREINAM
○ Até mesmo medalhistas olímpicos TREINAM
Coding Dojo
O que é? Para que serve? Benefícios?
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
Coding Dojo
Qual tal um desafio?
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
Coding Dojo
Dojo: Lista de Supermercado
FONTE: http://blog.billcode.com.br/2011/09/sugestao-para-primeiro-coding-dojo.html
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
Coding Dojo
Momento reflexão
● O que foi bom?
● O que pode melhorar?
Título em Arial Bold 24 pontosSubtítulo em Arial Bold 15 pontos ed vulputate fermentum
Test-Driven Development - TDD
Era uma vez...
● 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...
- Moral da história -
Código de teste é tão importante quanto o de produção.
Era uma vez...
Test-Driven Development - TDD
Introdução ao TDD
Introdução ao TDD
● O que é “testar”?
● Conceitos - Tipos de testes
○ Unidade
○ Integração
○ Stress
○ Carga
○ Performance
○ Outros (Regressão, Mock, Stubs)
O que é TDD?
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.”
Pra quem o TDD é indicado?
● 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?
Motivação ao TDD
● 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
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
Como saber se escrevi “bons” testes?
● Setup longo?
● Setup duplicado?
● Testes demoram a rodar?
● Testes frágeis?
Introdução ao TDD
Porque o TDD funciona?
● 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?
“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
Test-Driven Development - TDD
As três Leis e o Ciclo TDD
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.
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?
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
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
Test-Driven Development - TDD
Refatoração, Princípios SOLID e a Lei de Demeter
O que é Refatoração?
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]
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
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
● ...
Refatoração
“Qualquer idiota pode escrever código que um
computador possa entender...”
Refatoração
“...Bons programadores escrevem código que
os seres humanos possam entender.”
Martin Fowler
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
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
Princípios SOLID
Importantes princípios de modelagem OO:
● Single Responsibility Principle - SRP
● Open/Closed Principle - OCP
● Liskov Substitution Principle - LSP
● Interface Segregation Principle - ISP
● Dependency Inversion Principle - DIP
Single Responsibility Principle
“Uma classe deveria ter um único motivo para mudar”
Single Responsibility Principle
● Coesão
● O que é responsabilidade?
● Equilíbrio
○ Rigidez / Fragilidade
○ Complexidade desnecessária
Single Responsibility Principle
“Um ponto de mudança só é um ponto de mudança se a
mudança realmente ocorrer”
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
Open/Closed Principle
“Entidades de Software (classes, módulos, funções, etc.)
devem ser abertas para extensão, mas fechadas para
alteração”
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
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
Interface Segregation Principle
“Clientes não deveriam ser forçados a depender de interfaces
que eles não utilizam.”
Interface Segregation Principle
Interface Segregation Principle
Dependency Inversion Principle
Dependency Inversion Principle
Dependency Inversion Principle
“Módulos de alto nível não devem depender de módulos de
baixo nível. Ambos os níveis deveriam depender de
abstrações.”
Dependency Inversion Principle
“Abstrações não deveriam depender de detalhes. Detalhes é
que devem depender de abstrações.”
Dependency Inversion Principle
Dependency Inversion Principle
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)
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)
Test-Driven Development - TDD
Tech Talk - Ferramentas e Frameworks
Referências eletrônicas
● Apresentação:
http://www.slideshare.net/cesarcneto/treinamento-tdd-atech OU
https://portal.atech.com.
br/share/page/site/treinamentos/documentlibrary
● Código fonte no GitHub: http://github.com/cesarcneto/tdd-
course
● Design Patterns e Refatoração: http://sourcemaking.
com/refactoring
● Blog do Aniche:
http://www.aniche.com.br/tag/tdd/
● Princípios de OO
http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod
Referências eletrônicas
● DbUnit
http://dbunit.sourceforge.net/howto.html
● Mockito
http://code.google.com/p/mockito/
● DOJOs
http://dojopuzzles.com/
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.