Tdd principios oo

2,330 views
2,248 views

Published on

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

Published in: Technology, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
2,330
On SlideShare
0
From Embeds
0
Number of Embeds
6
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • 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

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

    ×