Test-Driven Development - Introdução

Test-Driven
Development
hlegius

Test-Driven Development
TD.. o quê ?

Era uma vez…
Barbie Software Engineer

Era uma vez…
executa

Era uma vez…
SVN
versiona

Várias Barbie’s Software Engineer

Várias Barbie’s Software Engineer
Modificando a aplicação sem garantias !

… outro,
outro e tantos outros…
Resultados…

Desenvolvimento orientado à testes

Testa
Publica
Codifica
Forma non-TDD

Testa
Publica
Codifica
Forma non-TDD
Escreve o
teste
Cria a
implementação
Valida a
implementação
Incrementa o
teste
Evolui o design
da
implementação
A maneira focada em testes

Mas afinal, qual o objetivo do TDD ?

Mitigar bugs ?

Mitigar bugs ?
Evitar
re-testes ?

Mitigar bugs ?
Evitar
re-testes ?
Evoluir
o
design ?

Mitigar bugs ?
Evitar
re-testes ?
Evoluir
o
design ?
mimimi

Mitigar bugs ?
Evitar
re-testes ?
Evoluir
o
design ?
mimimi
Validar
o
escopo ?

… falando sobre agile
O Manifesto Ágil

… falando sobre design
Table Module

Table Module
 Fácil para gerar automáticamente;

Table Module
 Fácil para developers com pouca
experiência;

Table Module
experiência;
 One size fits all;

Table Module
experiência;
 Alto acoplamento; viola o SRP;

Table Module
experiência;
 Pouco flexível, e;

Table Module
experiência;
 Pouco flexível, e;
 Dados e comportamento estão
separados.


Table Module
Mais do mesmo: Transaction Script e Service Layer @ PoEAA por Fowler
Domain Model

… falando sobre princípios
S
O
L
I
D

S
O
L
I
D
ingle Responsibility Principle

S
O
L
I
D
pen Close Principle

S
O
L
I
D
pen Close Principle
iskov Substitution Principle

S
O
L
I
D
pen Close Principle
nterface Segregation Principle

S
O
L
I
D
pen Close Principle
nterface Segregation Principle
ependency Inversion Principle

Specification-Driven Design
Soa bem melhor e é menos confuso. 

• Focado na especificação;
• Evolução contínua, e;
• Documentação executável;
• Three-one
Tem como objetivos:

• Focado na especificação;
• Evolução contínua, e;
• Documentação executável;
• Three-one
• OODesign;
• Domain-Driven Design;
• Modelo rico;
• Integração Contínua, e;
• Deploy contínuo.
• Three-one
Tem como objetivos: Premissa para:

Arquitetura dos testes
Escreve o
teste
Cria a
implementação
Valida a
implementação
Incrementa o
teste
Evolui o design
da
implementação
• Escreve-se o teste com o mínimo possível;
• Procure focar-se na especificação;
• Não caia na tentação de codificar
algo antes;
• Verifique se o teste falha
sem a implementação, e;
• Certifique-se de que o teste está validando
o que está no documento de especificação.

Escreve o
teste
Cria a
implementação
Valida a
implementação
Incrementa o
teste
Evolui o design
da
implementação
• Implementação coesa, seguindo um
design simplista baseado no SOLID, por exemplo;
• Não rascunhe. Crie o necessário
para aquela implementação, baseado no
que leu até o momento, e;
• Não rode o teste até ter finalizado.

Escreve o
teste
Cria a
implementação
Valida a
implementação
Incrementa o
teste
Evolui o design
da
implementação
• Execute o teste. 

Escreve o
teste
Cria a
implementação
Valida a
implementação
Incrementa o
teste
Evolui o design
da
implementação
• Melhore o design do teste.

Escreve o
teste
Cria a
implementação
Valida a
implementação
Incrementa o
teste
Evolui o design
da
implementação
• Melhore o design da implementação.

E o modelo anêmico

• Alto acoplamento;
• SRP, e;
• Dificulta testes de unidade.

Design pattern: Service
• SRP, e;
• Dificulta testes de unidade.

• Viola SRP;
• Dificulta testes de unidade;
• Baixa legibilidade, e;
• Orientado à função.

• Viola SRP;
• Dificulta testes de unidade;
• Baixa legibilidade, e;
• Orientado à função.
Um factory ao init(), melhoraria :)

Ele, o symfony !
Design pattern arquitetônico: Table Module
Design pattern estrutural: Row Data Gateway

• SRP;
• Orientado à “tabelas”;
• One size fits all;
• Utiliza-se herença à composição, e;
• Fácil uso.

• Mudar a arquitetura, ou;
• Redobrar atenção aos princípios SOLID.

Design dos testes
Single Responsibility Principle;

Design dos testes
Baixo acoplamento

Design dos testes
Baixo acoplamento;
Doc block e annotations na classe

Design dos testes
Baixo acoplamento;
Doc block e annotations na classe;
Keep It Simple, Stupid.

Design dos testes
Qual o problema aqui ?

• Entender o que é realmente OO Design;

• Não esquecer dos princípios S.O.L.I.D;

• #nota TDD é validação de escopo, não
bug finder;

bug finder;
• Arquitetura é importante ! ;

bug finder;
• Design patterns não são balas-de-prata,
e;

bug finder;
• Design patterns não são balas-de-prata,
e;
• Refatore cedo, refatore regularmente *

E para criar testes…
http://www.phpunit.de ;)

Test-Driven Development - Introdução

Mais conteúdo relacionado

Mais procurados (20)

Destaque (6)

Semelhante a Test-Driven Development - Introdução (20)

Mais de Hélio Costa e Silva (6)

Último (19)

Test-Driven Development - Introdução