TDD: Test-Driven Development e Refatoração

Test-Driven Development - TDD
César Caetano Neto - ccaetano@atech.com.br

● 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

Apresentações e Expectativas

Apresentações e Expectativas
● Nome
● Biografia profissional
● Expectativas...
Testes: Todo mundo sabe, mas nem todos fazem (direito).

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

Coding Dojo
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.

Coding Dojo
Momento reflexão
● O que foi bom?
● O que pode melhorar?

Título em Arial Bold 24 pontos
Subtítulo em Arial Bold 15 pontos ed vulputate fermentum
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...

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 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.”

● 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çõ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

● 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

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?

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

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

Refatoração, Princípios SOLID e a Lei de Demeter

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”

● Coesão
● O que é responsabilidade?
● Equilíbrio
○ Rigidez / Fragilidade
○ Complexidade desnecessária

“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

“Entidades de Software (classes, módulos, funções, etc.)
devem ser abertas para extensão, mas fechadas para
alteração”

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

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.”

“Abstrações não deveriam depender de detalhes. Detalhes é
que devem depender de abstrações.”

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)

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.

TDD: Test-Driven Development e Refatoração

TDD: Test-Driven Development e Refatoração

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a TDD: Test-Driven Development e Refatoração

Semelhante a TDD: Test-Driven Development e Refatoração (20)

TDD: Test-Driven Development e Refatoração