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

 
Utilizando a Linguagem Ubíqua criamos um modelo de domínio através do Projeto Dirigido pelo Modelo (Model Driven Design – MDD). A idéia por trás de MDD é a de que o seu modelo abstrato deve ser uma representação perfeita do seu domínio. Tudo que existe no seu negócio deve aparecer no modelo. Só aparece no modelo aquilo que está no negócio.

Em um time que cria software temos de um lado os especialistas de negócio e de outro os desenvolvedores e arquitetos. Num processo ágil defendido pelo MDD a criação do modelo abstrato deve ser feita em grupo, com todas as pessoas juntas. Se arquitetos e analistas de negócio criarem o modelo sem a participação dos programadores, corre-se o risco de criar um modelo que não é implementável ou que usará uma tecnologia inadequada. Da mesma forma, se os programadores codificarem sem se basear num modelo consistente, provavelmente desenvolverão um software que simplesmente não serve para o domínio. Em DDD, parte das pessoas que modelam o domínio são necessariamente pessoas que colocam a mão em código (Hands-on Modelers). Se os programadores não se sentirem responsáveis pelo modelo ou não entenderem como o modelo funciona, então o modelo não terá relação alguma com o software produzido por essas pessoas.

O processo de maturação de um sistema desenvolvido usando MDD deve ser contínuo. O modelo servirá de guia para a criação do código e, ao mesmo tempo, o código ajuda a aperfeiçoar o modelo. O contato contínuo com o código trará insights aos programadores, que irão refatorar o código. Essa refatoração deverá ser feita não só no código, mas também no próprio modelo.

Nessa vida de programador maluco
Me aparece cada situação
De repente um cliente, uma proposta bruta
Pra pegar de um site informação

Você tá louco, esse tipo de crime eu não faço
Se quiser tenho uns amigos lá do sul
Faz pra mim que eu te pago com essa jóia cool

Te dou um ruby
Pra você roubar
Com o seu robô

Quer fazer robô?
É só usar ruby
É só usar ruby
Pra fazer robô

Há algum tempo, fizemos uma peça de teatro que ensina os conceitos de Domain Driven Design (DDD). O foco desse teatro é a parte de Projeto Estratégico (Strategic Design) de DDD. Essa peça é baseada no roteiro escrito pelo próprio Eric Evans. Em 2008, na QCON SF, eu participei de um Workshop de DDD com o Raph Johnson. Depois fiz a tradução do roteiro, que pode ser baixado aqui.

Para saber mais sobre DDD, leia esse post no meu blog.

Sábado eu dei uma palestra de 20 minutos no 4o. Locaweb TechDay. Gostei muito de ter explorado esse tema. Muitas das ideias foram baseadas no livro Pragmatic Thinking And Learning, do Andy Hunt, misturado com minhas experiências pessoais. Confesso que tenho muitas outras coisas a respeito desse mesmo assunto que eu ainda quero falar. Façam seus comentários para me ajudar!

Pensamento e Aprendizado Eficiente – Desvendando o Cérebro Humano from Locaweb on Vimeo.

I finally finished my M.Sc. degree in Computer Science. I already have the video, which is right now just in portuguese, but soon I’ll have subtitles in English. I’d like to thank everybody who came to watch the performance. I hope you have a lot of fun with it.

Thanks for my N95 I had two cameras filming the event, so I’ve got a great final result using Apple iMovie software for edition.

Here is the video, enjoy!