AgileAndArt

Nesse vídeo eu mostro as principais vantagens do uso de Injeção de Dependência e Testes com Dublês (Stubs, Mocks, Fake Objects, Spy, Dummy Objects).

Vídeo

Slides

Transcrição

Injeção de Dependência e Testes com Dublês

1. Conteúdo• Exemplo• Injeção de Dependência (DI)• Testes com Dublês (Doubles)
2. Exemplo
3. Continuando o Exemplo• Criando interface
4. Dependência• PhoneLister depende da interface e da implementação• Como depender somente da interface?
5. Idéia Básica – Injeção Injeção Framework Injeção de Dependência
6. Tipos de Injeção• Injeção Por Construtor
7. XML
8. Usando na aplicação
9. Fábrica de Objetos• Singleton – Instância única compartilhada do objeto – Uso padrão, mais comum – Objetos de serviço sem estado (stateless)• Protótipos – Cada chamada cria um novo objeto• Escopos de Objetos Customizados – Objetos armazenados fora do controle do container (ex: request, session em uma aplicação Web)
10. Fábrica de Objetos
11. Vantagens de usar Injeção de Dependência• Ajuda a escrever código que é fácil de testar: é só criar objetos e atribuir as propriedades desejadas usando os setters• Facilita boas práticas de programação: uso de interfaces no lugar de classes• Não envasivo: o código do sistema depende o mínimo possível da API do Framework• Dependências são explícitas e evidentes• Como os componentes não precisam procurar colaboradores em tempo de execução, o código fica mais fácil de escrever e manter
12. Frameworks para todas as linguagens• Java – Spring, PicoContainer, HiveMind• PHP – DIContainer• .NET – Spring.NET, PicoContainer.NET• Python – PyContainer, Spring Python• Ruby – Needle• Perl – IOC Module• Flex – Flicc• mais em http://en.wikipedia.org/wiki/Dependency_injection
13. DI – Linha do Tempo
14. Construtor ou Setter?• Construtor com parâmetros deixa claro o que é preciso para criar o objeto• Usando construtor evita campos imutáveis de serem alterados• Cuidado: construtores com muitos parâmetros podem ser um indicativo de objeto com responsabilidades demais• Construtor é ruim se tiver parâmetros simples como Strings: com setter você cria um método que identifica o que a string significa• Receita geral: comece com construtor e mude para setter se a coisa ficar complicada demais
15. Testes com Dublês (Doubles) DoubleDummy Stub Spy Mock FakeObject
16. Dummy Object• Objetos que nunca são usados, só servem para preencher parâmetros
17. Stub• Provê alguns dados estáticos que serão usados nos testes• Não funciona para outras coisas além do que está no teste
18. Spy• Muito parecido com Stub, mas com a diferença de que “grava” algumas coisas
19. O que são Mock Objects? Years later, Mock objects are still quite controversial, often misused and sometimes misunderstood. “Pintside Thoughts: Mock Objects History” —Tim McKinnon
20. O que são Mock Objects?• Cada pessoa entende de um jeito diferente• Terminologia ambígua• Ficou famoso inicialmente na comunidade JAVA & TDD Comportamento Estado testa interação entre testa o resultado dessas objetos interações
21. Código Mock
22. Fake Object• Têm uma implementação completa, mas simples• Não vai para produção• Exemplo: banco de dados em memória 23
23. Mocks nas Linguagens• Java – EasyMock, JMock, Mockito• Ruby – Mocha, RSpec?• .NET – NMock, Rhino Mocks• Perl – Test::MockObjects• C++ – Google Mocks• PHP – Simple Test for PHP
24. Testes com Doubles – Recapitulando DoubleDummy Stub Spy Mock FakeObject Preenche parâmetros
25. Testes com Doubles – Recapitulando DoubleDummy Stub Spy Mock FakeObject Provê Preenche dados para parâmetros os testes
26. Testes com Doubles – Recapitulando DoubleDummy Stub Spy Mock FakeObject Provê Provê Preenche dados para dados eparâmetros os testes grava
27. Testes com Doubles – Recapitulando DoubleDummy Stub Spy Mock FakeObject Provê Provê Verifica Preenche dados para dados e comporta-parâmetros os testes grava mentos
28. Testes com Doubles – Recapitulando DoubleDummy Stub Spy Mock FakeObject Provê Provê Verifica Implemen- Preenche dados para dados e comporta- taçãoparâmetros os testes grava mentos +simples
29. QuizDublês + Injeção de Dependência = Testes
30. Referências
    http://www.springframework.org/documentation
    http://martinfowler.com/articles/injection.html
    http://martinfowler.com/articles/mocksArentStubs.html
    http://xunitpatterns.com/
    Anil Hemrajani, Agile Java Development with Spring, Hibernate and Eclipse

O modelo de Dojo que estamos acostumados é o Dojo Randori, aquele em que temos uma dupla programando (o piloto e o co-piloto) e um telão para mostrar para o resto da plateia o código que está sendo feito. A cada 5 ou 7 minutos o co-piloto ocupa o lugar do piloto e alguém da plateia ocupa o lugar do co-piloto. No Randori, todo desenvolvimento é sempre feito usando TDD.

O Dojo Kake é uma modalidade diferente de Coding Dojo. No Kake, nós temos sempre duas ou mais duplas trabalhando simultaneamente. As duplas podem resolver o mesmo problema em linguagens diferentes ou problemas diferentes. Os turnos continuam sendo de 7 minutos, porém a plateia NÃO PODE ficar olhando a dupla programar. A ideia é sentar para programar sem ter a menor noção do que estava acontecendo antes. É uma simulação da vida real: você chega para trabalhar num projeto que já começou, tem código legado. O seu par deve conseguir te explicar o que foi feito até então e vocês precisam avançar com o código. Depois de 7 minutos, o seu par sai e agora fica com você a responsabilidade de explicar para o próximo o que foi feito e continuar resolvendo o problema. Algumas regras do Kake Dojo:

• Dois ou mais computadores, dependendo da quantidade de participantes
• Turnos de 7 minutos
• TDD, baby steps, refatorações continuam sendo obrigatórios
• Divertir-se é obrigação: bater papo, contar piadas, cantar uma música, jogar video game, vale TUDO, menos olhar os outros programando
• Comida durante toda a sessão (pizza, sanduíche de metro ou jantar gourmet)
• No final fazemos uma retrospectiva usando a técnica dos 6 chapéus

Algumas cenas do último Dojo Kake que realizamos em 2009 podem ser vistas no vídeo:

Vamos fazer um Dojo Kake na próxima 3a. feira, dia 17 de agosto as 20h. Quem estiver interessado em participar, mande um e-mail para mim: danicuki arroba gmail ponto com.

The idea of extracting abstractions is to identify the essence of a system and describe its most deeply characteristics with simple elements. To achieve this essence you need a lot of experience and sweat. You need mastery you programming skills and use the tools and programming languages in the most proper way. It is an Art.

Play the video bellow to see how refactoring was made by Pablo Picasso in his paintings:

First, the painter draw a ordinary bull, which can be recognized by a 5 year old child. Irrelevants parts are being remove at each new stage of the draw (there are 11 pictures), besides the main idea of the bull remains. The whole genious desconstruction proccess takes six weeks. Even with few drawn lines, the last painting can still clearly represent the bull. They are the animal’s essence.

Every capable programmer, software creator, needs to know how to recognize essential aspects of the domain he is programming for. The technic helps to execute it, but geniality is rooted in intuitive thinking and the artistic capacity of identifying and extracting the essence.

(Portuguese version)

Uma das técnicas mais usadas no desenvolvimento de software é a refatoração. Ela consiste em executar uma série de pequenos passos que visam deixar o código mais claro, mais bonito, mais elegante. Normalmente o resultado de uma refatoração é um projeto mais simples e de fácil manutenção. Muitas vezes a refatoração leva a criação de abstrações e generalizações no código.

Um exemplo simples: vamos supor que estejamos programando a classe de dados Pessoa. Essa classe contém atributos como nome, peso, idade, idioma que fala. Num segundo momento eu percebo que preciso inserir gatos no meu sistema. Então crio a classe Gato com os atributos nome, peso, sexo e cor do pelo. Em seguida percebo que criei uma ambigüidade. Ambas as classes Gato e Pessoa possuem atributos em comum. Através de uma refatoração, crio a classe Animal com os atributos em comum (nome, peso, sexo) e faço com que as classes Gato e Pessoa “herdem” as propriedades de animais.

A idéia de extrair abstrações é a de identificar a essência do sistema e descrever com elementos simples suas características mais internas. Para chegar na essência é preciso muita experiência e suor. É preciso programar muito bem e saber usar de forma maestral a linguagem e as ferramentas a disposição. É uma arte.

Observe como são feitas refatorações na pintura de Pablo Picasso na figura. Inicialmente o pintor desenha um touro completo e normal, que pode ser reconhecido por qualquer criança de 5 anos. A cada novo estágio do desenho (são 11 gravuras no total), as partes irrelevantes vão sendo retiradas, porém a idéia central do touro permanece. O processo de desconstrução do gênio dura 6 semanas. Mesmo com com pouquíssimos traços, o último desenho consegue representar claramente o touro. São os traços essenciais do animal.

Todo bom programador, criador de software, deve saber reconhecer os aspectos essenciais de um sistema. As técnicas ajudam na execução, mas a genialidade está no pensamento intuitivo e na capacidade artística de identificar e extrair da a essência.

Joca Torres defendeu nesse post algumas vantagens de usar métodos ágeis, do ponto de vista do gerente de produtos. O design incremental e o uso de iterações permite que o cliente veja mais rapidamente aquilo que já está pronto. A partir do momento que o cliente está usando nosso software, ele começa a PAGAR e a ter benefícios (e nós também!).

Porém, do ponto de vista do time de desenvolvimento, existem alguns cuidados que precisam ser tomados para que o software se torne “modificável” para atender as necessidades do cliente. Para entregar funcionalidade de forma incremental, você precisa ter um ambiente de desenvolvimento e uma base de código que facilite e permita essas entregas iterativas.

As práticas de XP são um guia para isso. O gerente de produtos tem muito contato com as práticas de planejamento (histórias, iterações, velocidade etc) mas em software não basta planejar. O código tem que ter alta qualidade e testes (de preferência automatizados). Para se testar, é necessário programar orientado a testes, ou seja, se você começou a fazer um software numa linguagem ou num ambiente que não facilite a criação e manutenção de testes, você está indo no caminho contrário da qualidade e da agilidade. Se você quer acompanhar as mudanças da tecnologia, da vontade do seu cliente e do dia-a-dia dos membros de sua equipe, tenha uma boa base de testes para seu software.

Para escrever bons testes, você precisa ter um design bom e simples. Para transformar seu código legado, obsoleto, em algo testável, você precisa ter bons conhecimentos em Programação Orientada a Objetos e Refatorações.

Quando o time de desenvolvimento é maior do que um time de uma única pessoa, o código será compartilhado. Para diminuir a entropia da comunicação entre pessoas que modificam o mesmo código, você utiliza programação pareada, padronização de código e integração contínua. Além disso, times ágeis não podem ter muito mais do que oito ou dez pessoas.

Resumindo, plano de iterações é parte essencial da agilidade, mas ela só é possível com práticas sustentáveis como testes automatizados, refatorações, integração contínua, propriedade coletiva de código, programação pareada etc.