Email
Favorite
Favorited ×
Download
Embed
Private Content
Copy and paste this code into your blog or website Copy Customize Close
We have emailed the verification/download link to "".
Login to your email and click the link to download the file directly.

To request the link at a different email address, update it here. Close
Validation messages. Success message. Fail message.

Check your bulk/spam folders if you can't find our mail.

Tweet

Loading…

Flash Player 9 (or above) is needed to view presentations.
We have detected that you do not have it on your computer. To install it, go here.

Tdd principios oo

by Alex Chastinet on May 28, 2011

1,654 views

Palestra apresentada em maio de 2011 sobre aplicar princípios OO para facilitar a criação de testes com TDD

Palestra apresentada em maio de 2011 sobre aplicar princípios OO para facilitar a criação de testes com TDD

Accessibility

View text version

Categories

Tags

tdd dip srp oo solid

Upload Details

Uploaded via SlideShare as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

File a copyright complaint

7 Embeds 898

http://javabahia.blogspot.com	722
http://otaviosantana.blogspot.com	130
http://javabahia.blogspot.com.br	33
url_unknown	9
http://feeds.feedburner.com	2
http://www.slideshare.net	1
http://otaviosantana.blogspot.com.br	1

Statistics

Favorites: 0
Downloads: 0
Comments: 0
Embed Views: 898
Views on SlideShare: 756
Total Views: 1,654

TDD foi criado por Kent Beck, autor da conhecida metodologia ágil XP. TDD é um elemento essencial do XP.
Basicamente, em TDD nos modificamos um pouco a ordem do desenvolvimento.
Escreva um teste com o comportamento que vc imagina que será atendido. Ex.: calcular o total de horas de um período
Implemente o código para que ele teste passe o mais rápido possível. Pode cometer pecados nessa parte...
Refatore o código, remove duplicações e os pecados cometidos na fase anterior.
Normalmente, programar com TDD não é difícil. Porém requer disciplina. O problema é que estamos acostumados a partir direto para a solução sem pensar muito nas decisões que tomamos enquanto implementamos. Para fazer TDD corretamente, precisamos de alguns conhecimentos que vão nos ajudar escrever um código mais “testável”.
Um código “testável” tem: 1 - responsabilidades bem definidas -> é fácil entender o objetivo da classe 2 – flexibilidade -> é possível isolar as unidades testadas substituindo dependências complexas Veremos alguns conceitos podem nos ajudar a alcançar um código assim...
Recorrer a princípios básicos da orientação a objetos pode nos ajudar a criar um código mais testável.
Princípio da responsabilidade única O que seria responsabilidade? -> muito genérico Toda classe deve ter um, e somente um, motivo para ser modificada Exemplo...
FolhaDePonto precisa calcular a carga horária do mês ...
Só que também está calculando a carga horária do dia...
FolhaDePonto tem duas razões para ser modificada -> quebra do SRP -> carga horária do mês -> carga horária do dia
Devido ao alto nível de acoplamento (o calculo está sendo feito internamente), não temos como testar de forma eficiente o cálculo da carga horária
Vamos aplicar o princípio SRP e separar as responsabilidades que encontramos -> Dia e Mês
A classe dia é responsável por calcular a carga horária do dia
A classe mês é responsável por calcular a carga horária do mês
Agora podemos testar o cálculo da carga horária do dia de forma simples
Princípio da Inversão de Dependência -> Um módulo de alto nível não deve depender de um módulo de baixo nível, ambos devem depender de abstrações. Exemplo...
O sistema de controle de pagamento deve validar uma compra se o cartão for valido. Ele depende de uma operadora de cartão para aprovar o pagamento.
Ele depende de uma operadora de cartão para aprovar o pagamento e realizar a transação.
A classe da Operadora de cartões se comunica com um servidor específico para realizar as transações de compras.
O módulo ControleDePagamento depende diretamente de uma módulo de baixo nível (OperadoraVisa) -> quebra do DIP
Problema -> Devido a este forte acoplamento, todos os testes irão se comunicar com o servidor e realizar transações reais!! ..Imagine o prejuízo...
Solução -> ao invés de dependermos de uma representação específica da operadora de cartões, vamos criar uma dependência de uma abstração da operadora de cartões e recebê-la por parâmetro.
Removemos a dependência para a classe...
... e recebemos uma instancia da abstração por parâmetro no construtor
Agora o código está mais flexível, dessa forma podemos substituir uma classe de operadora de cartão real por uma classe falsa para o ambiente de testes.
Criamos uma classe falsa, que se comporte como uma operadora mas que ñ realize operações reais. -> Está de acordo com a abstração da operadora de cartões de crédito.
Agora podemos testar sem correr o risco de ter um prejuízo de R$ 1000 toda vez que o teste for executado...
Outros princípios que podem nos ajudar a escrever um código mais testável DRY -> Don´t Repeat Your Self -> não se repita: remova duplicações do código YAGNI -> You Gonna need it -> não acrescente complexidade desnecessária Lei de Demeter -> evite os “vagões de trem” nos código -> carro.motor.iniciar_rotacao => carro.ligar

Tdd principios oo — Presentation Transcript

TDD Com princípios OO é mais fácil
TDD – Test Driven Development
Invertemos a ordem
Teste antes da implementação
Como fazer?
Mantra Vermelho – Verde - Refatoração
Refatoração
TDD não é difícil...
Código Testável
Princípios OO
SRP (Single Responsibility Principle)
Duas razões para mudar
Separar responsabilidades: Dia e Mês
DIP (Dependency Inversion Principle)
Dependência de uma classe específica (OperadoraVisa)
Depender da abstração
Podemos criar um ambiente para testes
Não é só isso DRY - Don’t Repeat Your Self Open Closed Principle Lei de Demeter Interface Segragation Principle
Obrigado! @alexchastinet [email_address]