TDD Projeto e Estrategias
Upcoming SlideShare
Loading in...5
×
 

TDD Projeto e Estrategias

on

  • 467 views

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

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

Statistics

Views

Total Views
467
Views on SlideShare
465
Embed Views
2

Actions

Likes
0
Downloads
17
Comments
0

1 Embed 2

http://gmsul2013.tumblr.com 2

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

TDD Projeto e Estrategias TDD Projeto e Estrategias Presentation Transcript

  • DesenvolvimentoBaseado em TestesProjeto e EstratégiasEduardo Mendesedumendes@gmail.com
  • @dudumendesIntrodução
  • @dudumendesIntroduçãoO que se quer de um bom projetoPrincípios para alcançarSituações que esclareçam
  • @dudumendesManutenibilidade
  • @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
  • @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
  • @dudumendesCombinação decomponentesComo dividir o código em componentes?Quais os limites das interfaces de comunicação?
  • @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
  • @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
  • @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
  • @dudumendesExcesso de exposição master.getModelisable() .getDockable() .getCustomizer() .getSaveItem. setEnabled(TRUE)
  • @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”
  • @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
  • @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
  • @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
  • @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
  • @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
  • @dudumendesmoneyEditor.getAmountField().setText(String.valueOf(money.amount)moneyEditor.getCurrencyField().setText(money.currencyCode)
  • @dudumendesmoneyEditor.setAmountField(money.amount)moneyEditor.setCurrencyField(money.currencyCode)
  • @dudumendesmoneyEditor.setValue(money);
  • @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
  • @dudumendesTDD x Princípios
  • @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
  • @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
  • @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
  • @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”
  • @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
  • @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
  • @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
  • @dudumendesTestes e dependências
  • @dudumendesContexto Dependencia! Componente! Composição! Associação!
  • @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
  • @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
  • @dudumendesEstratégia Componente!
  • @dudumendesEstratégia Falso Mock! Componente! Falso Mock! Falso Mock!
  • @dudumendesDublês de TestesTest DoublesMESZAROS
  • @dudumendes DoubleDummy Fake Mock Stub Spy
  • @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
  • @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
  • @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
  • @dudumendesStub Fonte: MEZAROS, 2007
  • @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
  • @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
  • @dudumendesSpy Fonte: MEZAROS, 2007
  • @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
  • @dudumendesMock Fonte: MEZAROS, 2007
  • @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/