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

MiniPLoP 2011

Software developers have long observed that certain patterns recur and endure across different applications and systems. The growing interest in Design Patterns, Architectural Patterns, Analysis Patterns, Pedagogical Patterns, and so on, represents an effort to catalog and better communicate knowledge, providing handbooks of proven solutions to common problems.

MiniPLoP brings together researchers, educators, and practitioners whose interests span a remarkably broad range of topics and who share an interest in exploring the power of the pattern form. MiniPLoP invites you to add your expertise to the growing corpus of patterns. MiniPLoP focuses on improving the expression of patterns. You will have the opportunity to refine and extend your patterns with the help from knowledgeable and sympathetic fellow pattern enthusiasts. You will also be able to discuss applications of patterns in industry and academia.

Highlights of the conference include an international tutorial, an introduction to pattern writing, an international keynote, and the writer’s workshops.

This version of MiniPLoP has the goal to encourage the beginners in the pattern world and to put together the Latin-american pattern community. The MiniPLoP program will accept submissions for the Writers’ Workshop (WW) track. The papers should document patterns and pattern languages and they will be workshopped in the traditional PLoP format.

Visit the event website

General Chairs

Eduardo Martins Guerra (ITA, Brasil)

Fabio Kon (IME/USP, Brasil)

Program Co-chairs

Claudio Sant’Anna (UFBA, Brasil)

Joseph W. Yoder (U. Illinois/The Refactory, Inc, USA)

Local Organization

Allan Machado da Silva (ITA, Brasil)

Carlos Eduardo Moreira dos Santos (IME/USP, Brasil)

Daniel Cukier (IME/USP, Brasil)

José Roberto Campos Perillo (ITA, Brasil)

Jefferson de Oliveira Silva (ITA, Brasil)

Program Committee

Ademar Aguiar (INESC Porto/University of Porto, Portugal)

Brian Foote (Industrial Logic, Inc, USA)

Eduardo Guerra (ITA, Brazil)

Filipe Correia (Porto University, Portugal)

Gustavo H. Rossi (Lifia/UNLP, Argentina)

Hugo Sereno Ferreira (INESC Porto/University of Porto, Portugal)

Jerffeson Teixeira de Souza (UECE, Brazil)

Linda Rising (Independent Consultant, USA)

Lise Hvatum (Schlumberger, USA)

Tiago Massoni (DSC/UFCG, Brazil)

Rebecca Wirfs-Brock (Wirfs-Brock Associates, USA)

Richard Gabriel (IBM Research, USA)

Roberta Coelho (DIMAp/UFRN, Brazil)

Rohit Gueyi (DSC/UFCG, Brazil)

Rosana Braga (ICMC/USP, Brazil)

Rossana Andrade (DC/UFC, Brazil)

Sergio Soares (CIn/UFPE, Brazil)

Uirá Kulesza (DIMAP/UFRN, Brazil)

Additional Shepherds

Daniel Cukier (IME/USP, Brasil)

Jefferson de Oliveira Silva (ITA, Brasil)

Tarciane Andrade (UECE, Brasil)

 
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.

Doutores Discutindo

Há seis meses, decidi me embrenhar no mundo acadêmico e iniciar um longo período (de no mínimo 3 anos) de doutorado. Desde então, várias pessoas me perguntam “Como está indo?”, “Está gostando?” e, principalmente, “O que é doutorado? (também conhecido como PhD)”. Eu ainda não tenho uma resposta clara para essas perguntas, mas tenho certeza que quando estiver mais maduro, farei um post sério sobre isso aqui no meu blog. Por hora, vou deixar um texto que eu recebi em uma das aulas, que me parece ser [no momento] a definição mais apropriada para doutorado. É uma brincadeira, mas que tem um certo fundo de verdade…

SABEDORIA POPULAR

Rapadura é doce, mas não é mole, não!!!

ENSINO FUNDAMENTAL

Açúcar mascavo em tijolinhos tem o sabor adocicado, mas não é macio ou flexível.

ENSINO MÉDIO

Açúcar não refinado, sob a forma de pequenos blocos, tem o sabor agradável do mel, porém não muda de forma quando pressionado.

GRADUAÇÃO

O açúcar, quando ainda não submetido à refinação e, apresentando-se em blocos sólidos de pequenas dimensões e forma tronco-piramidal, tem sabor deleitável da secreção alimentar das abelhas; todavia não muda suas proporções quando sujeito à compressão.

MESTRADO

A sacarose extraída da cana de açúcar, que ainda não tenha passado pelo processo de purificação e refino, apresentando-se sob a forma de pequenos sólidos tronco-piramidais de base retangular, impressiona agradavelmente o paladar, lembrando a sensação provocada pela mesma sacarose produzida pelas abelhas em um peculiar líquido espesso e nutritivo. Entretanto, não altera suas dimensões lineares ou suas proporções quando submetida a uma tensão axial em consequência da aplicação de compressões equivalentes e opostas.

DOUTORADO

O dissacarídeo de fórmula C12H22O11, obtido através da fervura e da evaporação de H2O do líquido resultante da prensagem do caule da gramínea Saccharus officinarum Linneu, 1758, isento de qualquer outro tipo de processamento suplementar que elimine suas impurezas, quando apresentado sob a forma geométrica de sólidos de reduzidas dimensões e arestas retilíneas, configurando pirâmides truncadas de base oblonga e pequena altura, uma vez submetido a um toque no órgão do paladar de quem se disponha a um teste organoléptico, impressiona favoravelmente as papilas gustativas, sugerindo impressão sensorial equivalente provocada pelo mesmo dissacarídeo em estado bruto, que ocorre no líquido nutritivo da alta viscosidade, produzindo nos órgãos especiais existentes na Apis mellifera, Linneu, 1758. No entanto, é possível comprovar experimentalmente que esse dissacarídeo, no estado físico-químico descrito e apresentado sob aquela forma geométrica, apresenta considerável resistência a modificar apreciavelmente suas dimensões quando submetido a tensões mecânicas de compressão ao longo do seu eixo em consequência da pequena capacidade de deformação que lhe é peculiar.

It was a great event and I’m very happy to be part of it. QCON was awesome! I hope you enjoy the pictures

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

No mês passado participamos de uma atividade promovida pela ThoghtWorks Brasil em Porto Alegre e organizada pelo Carlos Villela (CV). Eles aproveitaram a ocasião do FISL12 para organizar esse pequeno evento no confortável escritório que fica dentro do campus da PUC-RS. Foi pequeno em relação ao número de participantes (acho que éramos em uns 30), mas enorme em divertimento e aprendizado.

A brincadeira era uma espécie de Dojo, com regras um pouco exóticas. A ideia original foi do Nat Pryce e do Ivan Moore, e eles chamaram de Scrapheap Challenge, por causa do programa de TV, mas eu resolvi re-batizar para Dojo Ojod (um palíndromo de Dojo ao contrário), pois foi exatamente assim que o CV definiu (e que eu concordo muitíssimo): um Dojo ao contrário.

Vamos lembrar que o objetivo principal do Coding Dojo é aprender, num ambiente amistoso e divertido. Nesse quesito o Dojo Ojod é bem semelhante ao Dojo Randori (a mais tradicional modalidade de Dojo). O que muda é que no Dojo Randori temos que fazer TDD, seguir passos de bebê e escrever o melhor código possível, refatorando, deixando ele elegante. No Dojo Randori não temos o objetivo de resolver o problema proposto. Já no Dojo Ojod o objetivo principal é resolver o problema, só que de uma maneira não convencional. Na verdade, a regra é resolver o problema com o maior número possível de gambiarras e escrevendo o mínimo de linhas de código que pudermos. Vale usar qualquer coisa, desde scripts nojentos até ferramentas prontas na Web, planilha de Excel, tudo que tem de mais abominável em matéria de desenvolvimento de software. O importante é favorecer a reutilização.

Aqui vão as instruções de como organizar um Dojo Ojod você mesmo:

1. Exponha a lista de problemas (veja os exemplos de problemas abaixo). Normalmente é bem ter umas 5 opções.
2. Cada pessoa escolhe que problema quere fazer. Dessa forma todos se dividirão em alguns grupos.
3. O ideal são grupos de 4 a 6 pessoas. Tente fazer com que isso aconteça, re-arranjando as pessoas caso seja necessário.
4. Cada grupo irá trabalhar isoladamente por 2 horas (cada grupo pode se sub-dividir como preferir se achar melhor).
5. Durante o trabalho, lembrem-se de que o objetivo principal é resolver o problema com o maior número possível de gambiarras e escrevendo o mínimo de linhas de código.
6. Passadas 2 horas, cada grupo irá apresentar para os outros a solução encontrada (acreditem, isso será muito engraçado!).

Um dos requisitos mais difíceis para esse tipo de Dojo é justamente criar problemas interessantes de serem resolvidos nesse tempo (2 horas). Vou passar aqui a lista dos problemas que tivemos na ThoughWorks:

O grupo que eu participei resolveu o problema número 3 (a música mais sortuda da cidade). Para quem está curioso, veja a solução no meu github e ouça um trecho dessa música maravilhosa.

Essa dinâmica de Dojo nos faz perceber como existem infinitas maneiras de se resolver um problema e como podemos re-utilizar soluções prontas, agrupando-as da maneira adequada, sem a necessidade de escrevermos muito código.

Organize você um Dojo desses na sua comunidade e deixe o seu comentário aqui de como foi o resultado. Se conseguirem inventar novos problemas, por favor, me conte também

Não deixe de ler uma descrição mais detalhada do Scrapheap Challenge no site do Nat Pryce.

Uma contribuição inovadora da USP Palestra realizada pelo professor do Instituto de Fisica Giorgio Moscati pelo Centro de Competência de Software Livre (CCSL) no IME-USP em 19 de maio de 2011