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ô

Here are the slides the presentation slides about Ruby Robots I gave in RsOnRails

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.

Ontem, durante o I CBSoft (Congresso Brasileiro de Software), Rafael Prikladnicki e eu (representando a Locaweb e a Agilcoop) demos um mini-curso de Introdução a Métodos Ágeis. Ficamos muito felizes em saber que foi um dos cursos mais procurados do evento. No início do curso, fizemos uma dinâmica com os participantes para que escrevessem em post-its suas experiências. Eles teriam que nos dizer sua opinião sobre por que um projeto de software fracassa ou por que um projeto de software tem sucesso. Baseado nessas respostas, fomos moldando o curso, tentando responder o que Métodos Ágeis ajuda a resolver e o que não.

Uma das coisas mais interessantes foi o fato de que eu não conhecia o Rafael antes. Nós organizamos o esqueleto do curso por e-mail, nos encontramos um dia antes para acertarmos os últimos detalhes e improvisamos muito durante a apresentação. Assumimos a filosofia ágil e íamos apresentando os assuntos que mais interessavam ao cliente (no caso o nosso público). Foi uma experiência divertida.

Para quem quiser ver um pouco do conteúdo do mini-curso, aqui vão os slides.

Desde a apresentação da minha defesa de mestrado muita coisa aconteceu. Recebi comentários de várias pessoas do Brasil todo sobre a defesa e fiquei extremamente feliz com a repercussão, tanto no meio acadêmico quanto na indústria. Tive oportunidade de conhecer e conversar com muita gente interessante por causa do trabalho que fiz. Entre essas pessoas, gostaria de compartilhar aqui uma parceria que surgiu e que ainda tem muito para evoluir.

Ano passado eu estava lendo uma matéria na revista Mente e Cérebro e um artigo me chamou muito atenção. Ele foi escrito pela professora e pesquisadora Maira Fróes. O artigo falava sobre a união da Arte e da Ciência. Várias das ideias apresentadas tinham muita relação com a minha dissertação de mestrado e a minha visão pessoal sobre o que eu acredito ser Ciência.

Escrevi para a Maira parabenizando pelo artigo. Contei da minha defesa, mostrei para ela o vídeo e me ofereci para unirmos força e trabalharmos juntos em algo. Ficamos encantados, um com as ideias do outro e combinamos um encontro no Rio de Janeiro para conversarmos sobre como poderíamos de fato trabalhar juntos para evoluir esse projeto. Nesse momento ainda estamos numa fase embrionária, mas que já temos muitos elementos ricos e um bando de gente competente e talentosa envolvida no grupo, que é coordenado pela Maira.

Algumas pesquisas já estão sendo feitas e a primeira delas, que já mostrou resultados interessantes, é o de introduzir elementos artísticos em aulas de anatomia. A ideia é transformar a sala de aula de anatomia, normalmente fria e insensível, em algo vivo, emocionante. A inclusão da emoção e sensibilidade no ensino pode trazer benefícios enormes para os alunos, tanto no nível do aprendizado quanto no da experiência e vivência pessoal de cada um.

Semana passada estive junto com o grupo da Maira em Caxambu, no XXXIV Congresso da Sociedade Brasileira de Neurociências e Comportamento. Tive a oportunidade de fazer uma apresentação sobre a minha visão de unir Arte e Ciência. Vejam os slides da palestra:

Também gostaria de compartilhar aqui um pequeno vídeo da exposição criada pelo grupo da Maira e que estava sendo realizada dentro do Congresso. A exposição se chama EXPO UMA CIÊNCIA SENSÍVEL (grupo Anatomia das Paixões). Infelizmente o vídeo não expressa toda a emoção que é adentrar uma sala escura de corpos dançantes, verdadeiras obras de artes, e experimentar sensações de aprendizado sobre nomes de ossos humanos nesse ambiente.

Gostaria de deixar aberto aqui um espaço, para que as pessoas pudessem sugerir ideias ou compartilhar vivências de como podemos integrar melhor não só a Arte com a Ciência, mas Arte com Computação, ou Arte com ambiente de trabalho, de maneira que possamos incluir e integrar emoção humanas nas vivências do dia-a-dia. Todos são bem vindos a participar desse grupo!

Here are the slides of a talk I gave to young people, from  14 to 16 years, about how is the life of a Computer Scientist. Some time ago, I’ve made a blog post with 15 question and answers about Computer Science. I hope this presentation and the blog post can be useful to teenagers. I know choosing the course which will be your life for the next 4 or 5 years is not an easy task, so, the more information available the better. And don’t forget: every time is time to change and make other choices.

Para quem quiser, seguem os slides da minha palestra no Encontro Ágil 2009: