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

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.