TDD Projeto e Estrategias

390 views
296 views

Published on

Considerações sobre um bom projeto orientado a objeto e como o TDD apoia a alcançar um bom projeto

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

  • Be the first to like this

No Downloads
Views
Total views
390
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
20
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

TDD Projeto e Estrategias

  1. 1. DesenvolvimentoBaseado em TestesProjeto e EstratégiasEduardo Mendesedumendes@gmail.com
  2. 2. @dudumendesIntrodução
  3. 3. @dudumendesIntroduçãoO que se quer de um bom projetoPrincípios para alcançarSituações que esclareçam
  4. 4. @dudumendesManutenibilidade
  5. 5. @dudumendesO sistema OO com TDDSeguir o processo do TDD Construir o sistema através de uma funcionalidade de cada vez Quantidade de código crescendo a única maneira de continuar a entender e mantê-lo estruturação das funcionalidades em objetos, objetos em módulos, módulos em
  6. 6. @dudumendes02 estratégias SoC (Separation of Concerns, Parnas, 1974) quando se deseja mudar o comportamento de um sistema, deve-se puder ir direto ao ponto Níveis altos de abstração Evita-se o trato com a complexidade através da abstração combinação de componentes ao invés de variáveis e estruturas de controle
  7. 7. @dudumendesCombinação decomponentesComo dividir o código em componentes?Quais os limites das interfaces de comunicação?
  8. 8. @dudumendesEncapsulamento xOcultaçãoEncapsulamento O comportamento de um objeto só deve ser alterado através de sua própria API Consequência Ausência de dependências inesperadas entre componentes sem relação Controle do quanto uma mudança em um objeto irá impactar em outras partes do sistemaOcultação de informações Um objeto esconde como implementa suas funcionalidades através da abstração de sua API Ignoram-se os detalhes de baixo nível
  9. 9. @dudumendesDentro e fora do objeto Uma decisão de projeto O que está dentro e fora de cada objeto? para que o objeto possua uma API coerente Comunicação entre objetos mensagens diretamente com seus vizinhos Importância Facilidade de uso de um objeto Como ele contribui para a qualidade do sistema
  10. 10. @dudumendesExcesso de exposiçãoConsequências Vizinhos farão parte do próprio trabalho do objeto Comportamento distribuído através de muitos objetos Forte acomplamento Alto custo de manutenção
  11. 11. @dudumendesExcesso de exposição master.getModelisable() .getDockable() .getCustomizer() .getSaveItem. setEnabled(TRUE)
  12. 12. @dudumendesEvitar “e”, “ou” e “mas” Cada objeto deve possuir uma única e bem definida funcionalidade Guia de quando adicionar funcionalidades a um novo objeto criar um novo vizinho para o mesmo Deve-se poder descrever o que um objeto faz sem usar conjunções como “e” , “ou”
  13. 13. @dudumendesTipos de Vizinhoso que estes objetos dizem um ao outro? Dependência Contexto A funcionalidade de um objeto depende dos serviços de outros objetos Consequência Não é possível criar um objeto sem os demais
  14. 14. @dudumendesTipos de Vizinhoso que estes objetos dizem um ao outro? Notificações Contexto Objetos que precisam se manter atualizados das atividades de seus vizinhos Não precisa saber necessariamente quem está “ouvindo” Consequência Desacoplamento de vizinhos
  15. 15. @dudumendesTipos de Vizinhoso que estes objetos dizem um ao outro? Ajustes Contexto Vizinhos que ajustam o comportamento dos objetos a partir das necessidades mais amplas do sistema Exemplo Objetos de Layout que ajustam a disponibilização de elementos
  16. 16. @dudumendesO que mais importa é ocontextoNão são regrasNos ajudam a pensar no projeto do código a partir daperspectiva de suas colaborações O que é um objeto válido?Um mesmo objeto pode atuar em mais de um papel
  17. 17. @dudumendesComposições simplesmais que a soma das partes Utilização de Associações Objetos compostos devem fornecer um comportamento mais simples que a junção de todos os seus componentes devem ocultar a existência de seus componentes expor uma abstração simples de seus vizinhos
  18. 18. @dudumendesmoneyEditor.getAmountField().setText(String.valueOf(money.amount)moneyEditor.getCurrencyField().setText(money.currencyCode)
  19. 19. @dudumendesmoneyEditor.setAmountField(money.amount)moneyEditor.setCurrencyField(money.currencyCode)
  20. 20. @dudumendesmoneyEditor.setValue(money);
  21. 21. @dudumendesIndependência de contextoContexto Um objeto não deve ser implementado dependendo de conhecimento sobre o sistema Se necessário, ele deve receber esta informaçãoObjetos com contextos independentes Relações explícitas Objetos mais simples Sistema mais fácil de absorver mudanças
  22. 22. @dudumendesTDD x Princípios
  23. 23. @dudumendesPrincípios SOC Saber o que faz Abstração Não como faz Encapsulamento Unidades coerentes Ocultação de Independentes do informações ambiente Vizinhança Flexibilidade Composições simples Adaptação mudanças
  24. 24. @dudumendesTDD / Princípios Iniciar com um teste Descreve-se o que um objeto fa antes de considerar o como Foco nível de abstração correta Teste com intenção obscura mistura de conceitos não é hora de codificar Ocultação de informações decidir o que deve ser visível a partir do objeto
  25. 25. @dudumendesTDD / Princípios Manter testes legíveis Limite de escopo Testes muito grandes Sujeitos são muitos grandes quebrar em componentes menores Objetos compostos devem possuir separação clara de interesses passíveis de testes simples
  26. 26. @dudumendesTDD / Princípios Conhecimento das dependências Um sujeito em teste precisará de suas dependências Consequência Passamos a conhecer as dependências Melhora-se o entendimento Apóia a independência de contexto Dependências implícitas pode ser trabalhoso de preparar pode ser necessário “emagrecê-lo”
  27. 27. @dudumendesInterface / Protocolo Interface descreve se 02 componentes se encaixam Protocolo descreve se eles trabalham juntos O TDD torna visível o protocolo de comunicação entre os objetos
  28. 28. @dudumendesAdicionando funcionalidadesSurgimento de códigos de novas áreas Ao iniciar novas áreas de código deve-se esquecer temporariamente julgamentos sobre projeto apenas escrever código sem se importar com estruturaConsequência Ganha-se confiança e experiência Entende-se as intenções do código Entretanto código pode se tornar muito grande
  29. 29. @dudumendesTeste informamFragmentar um objeto se ele se tornou muito grande para se testar facilmente se falhas de teste se tornaram difíceis de se interpretar se o domínio está disperso
  30. 30. @dudumendesTestes e dependências
  31. 31. @dudumendesContexto Dependencia! Componente! Composição! Associação!
  32. 32. @dudumendesContextoPara aplicações que dependem de ambientes deexecução, escrever testes pode ser um desafioTestes precisam ser estáveis e quando executadosrepetidamente eles devem gerar os mesmosresultadosÉ necessário um modo de controlar o ambiente emque os testes são executados
  33. 33. @dudumendesSoluçõesConfigurar o ambiente real pode ser prático e trazer benefícios reais nem sempre é viávelSimular o que está faltando substituindo por um por algo falsificado que se comporte do mesmo jeito
  34. 34. @dudumendesEstratégia Componente!
  35. 35. @dudumendesEstratégia Falso Mock! Componente! Falso Mock! Falso Mock!
  36. 36. @dudumendesDublês de TestesTest DoublesMESZAROS
  37. 37. @dudumendes DoubleDummy Fake Mock Stub Spy
  38. 38. @dudumendesTestes DublêsDummy Objects são repassados como parâmetros mas nunca utilizados it “deve possuir um nome” do e = Endereco.new c = Cliente.new(“Cliente 1”, e) expect(c.nome).to eql(“Cliente 1”) end
  39. 39. @dudumendesTestes DublêsFake Objects Objeto que possuem implementações funcionais, mas normalmente utilizam algum atalho que os torna inadequados para produção Ex: Bancos de dados em memória
  40. 40. @dudumendesTestes DublêsStubs Objetos que providenciam respostas pré- configuradas para as chamadas feitas durante os testes Normalmente, não respondem nada além do que esteja previamente programado para o teste As respostas são estáticas
  41. 41. @dudumendesStub Fonte: MEZAROS, 2007
  42. 42. @dudumendesdescribe Statement doit “usa o nome do cliente” do cliente = double(‘cliente’) cliente.stub(:nome).and_return(“Joao”) statement = Statement.new(cliente) statement.generate.should == “Sentenca do Joao”end
  43. 43. @dudumendesTestes DublêsSpy Comportamento semelhante ao Mock, mas as verificações de comportamento são realizadas após o método testado ser chamado É capaz de verificar se um determinado método foi chamado pois pode gravar informações
  44. 44. @dudumendesSpy Fonte: MEZAROS, 2007
  45. 45. @dudumendesTestes DublêsMocks Expectativas dos objetos são pré-programadas antes de se executar um método a ser testado Objetos fornecem o comportamento correto das chamadas que esperam receber
  46. 46. @dudumendesMock Fonte: MEZAROS, 2007
  47. 47. @dudumendesBibliografia FOWLER, Martin. “Mocks aren’t Stubs”. FREEMAN, Steve; PRYCE, Nat. Growing Object- Oriented Software, Guiaded by Tests. Addison-Wesley. MESZAROS, Gerard. xUnit Test Patterns: RefactoringTest Code. Addison-Wesley: 2007 MESZAROS, Gerard. xUnitTest Patterns.com. http:// xunitpatterns.com/

×