Tdd e projeto_comperio

972 views

Published on

Published in: Technology, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
972
On SlideShare
0
From Embeds
0
Number of Embeds
302
Actions
Shares
0
Downloads
3
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • - Dispersão da produção acadêmica Falar da existencia de varias atividades pertinentes ou relacionadas à pesquisa e extensão que não são catalogadas ou centralizadas para maior proveito da  comunidade   Dificuldade na comunicação entre participantes de projetos e sociedade academica Ausencia de meios que possibilitem uma comunicação efetiva entre participantes de projetos(artigos,PIC,TCC) e demais pessoas do instituto(corpo discente e docente)   Justificar a posição do IST-Rio como uma I.E(instituição de ensino) que busca a excelencia através do ensino e produção científica Mostrar para outras instituições e pessoas a produção científica que ocorre dentro do instituto Centralização de esforços para aprimoramento de P&E   A centralização de esforços permite que pesquisas sejam relacionadas para a geração de algo maior...  
  • Um sistema capaz de manter informações sobre a Pesquisa e extensão(P&E) desenvolvida no Instituto - sistema vaia rmazenar informações de usuários, projetos,artigos e prover meios de comunicação. Portal para divulgação da produção acadêmica - centralização das informações possibilitando o acesso das mesmas por toda a sociedade Disponibilização de ferramentas para comunicação Estreitar o vinculo entre os pesquisadores,alunos, professores e etc.. com intuito de centralizar o esforço Software web totalmente gratuito e open source   Possibilitar que a o software possa ser extendido por outros academicos e que este seja acessível para toda a sociedade
  • 10:00- Resolução de bugs no componente de CPF que é utilizado em 48 telas do sistema..   A cada bug consertado temos que testar 48 telas. O pior é quando a tela de número 46 apresenta um bug.. hora de recomeçar   14:00 -Integração com uma biblioteca de terceiro para calculo financeiro   Você vai fazer a integração sem saber se a biblioteca funciona bem? e quando a versão for alterada? temos que testar tudo novamente? 16:00-Integração com código desenvolvido pelo programador jr da equipe. você pega o código e não entende nada! todos os membros são publicos e os nomes são super parecidos, você não faz idéia de como usar..
  •   intenção: dar idéia de como testar é importante...   - falar como é fácil introduzir erro quando em manutenção ou em adição de qunciionalidade é feita - Sistema já têm muitos problemas de atraso dos prazos, de gerência, etc... e quando for entregue precisa funcionar bem  - falar de quando surgiu os conceitos de teste de sofware
  • -Exibir um rapido exemplo
  • Design por contrato(DBC)‏ Falar sobre a importancia do contrato de um método, caso um método não tenha um contrato não pode ser testado, Falar sobre bertrand meyer e eifel, a primeira implementação de DBC   XP   Falar sobre a valorização dos testes com o TDD de kent beck   Mais alguma coisa? não lembro...
  • -Documentação executável Documentação tende a ficar desatualizada logo uma abordagem diferente é colocar a documentação o mais proximo possível do software. E nada como documentação que reflete o código -Detecção de erros em tempo de programação -No início parece ser mais rapido apertat o botão compilar e verificar se aquilo funcionou. O problema é quando você aperta o compilar pela quinta vez.. O teste começa a ser mais valioso.. e ainda perdura durante toda a vida do software -Confiança Ter certeza que você pode dar o proximo passo..
  • Disciplina é liberdade Desenvolvimento de maneira disciplina você vai obter o controle sobre o comportamento do seu código e assim será possivel alterá-lo com liberdade   Abandone o debug! Falar sobre a nossa experiencia com o comperio, eu só rodo a aplicação quando quero ver layout, todo o server side fica com testes unitários   Programar por coincidência saiba como seu código se comporta quando você passa um valor nulo. E quando você passa um valor limite?   Aprender sobre os requisitos antes de escrever os testes -Escrevendo os testes você tem mais uma chance de refletir sobre a melhor implementaçao ou até a API publica que você está construindo   Ser o primeiro cliente do seu código  Eat you own dog food, você não vai escrever um código que vai te fazer perder o almoço vai?   Garantir uma cobertura de código de 100% Saber que todo o sistema pode ser testado com um click  
  • Podemos mostrar um exemplo prático
  • Automaticos -Podem ser executados com apenas um click Replicáveis Deve ser possível rodar os testes em qualquer ambiente de desenvolvimento Independentes -A ordem de execução não pode influcneicar os testes, isso acontece bastante quanto estamos testando conexão com banco de dados sem mocks
  • Podemos mostrar um exemplo realizado na hora: uma calculadora por exemplo, lógico que vamos construir o código antes!!
  •     Testes unitários não são de aceitação   - testes unitários testam código e integração dos mesmos mas não ações totalmente reais dos usuários  Testes fazem apenas simulações   Por esse motivo o sistema  não pode deixar de ser testado por um ser humano em um caso real
  • Falar sobre a possibilidade da criação de Dojo do ist-Rio. Explicar qual a ideia de dojo: -qq linguagem é bem-vinda -Tem que ser divertido(pipoca e suco) -Pair programming
  • Tdd e projeto_comperio

    1. 1. Projeto Comperio  e Desenvolvimento dirigido por testes(TDD)‏ Alunos:           Flavia Fortes,             Higor Ramos e          Renan Cabral
    2. 2. Situação problema <ul><ul><li>Dispersão da produção acadêmica do IST-Rio </li></ul></ul><ul><li>  </li></ul><ul><ul><li>Dificuldade na comunicação entre participantes de projetos e sociedade acadêmica </li></ul></ul><ul><li>  </li></ul><ul><ul><li>Justificar a posição do IST-Rio como uma instituição de ensino que busca a excelência através do ensino e produção científica </li></ul></ul><ul><li>  </li></ul><ul><ul><li>Centralização de esforços para aprimoramento de P&E(Pesquisa e extensão) </li></ul></ul>
    3. 3. Solução computacional <ul><ul><li>Um sistema capaz de manter informações sobre a P&E desenvolvida no Instituto </li></ul></ul><ul><li>  </li></ul><ul><ul><li>Portal para divulgação da produção acadêmica </li></ul></ul><ul><li>  </li></ul><ul><ul><li>Disponibilização de ferramentas para comunicação </li></ul></ul><ul><li>  </li></ul><ul><ul><li>Software web totalmente gratuito e open source   </li></ul></ul><ul><li>  </li></ul><ul><ul><li>Inicialmente desenvolvido em C# na plataforma DotNet </li></ul></ul>
    4. 4. Outras possibilidades <ul><ul><li>Geração de uma Rede de relacionamento voltada à educação e Pesquisa </li></ul></ul><ul><li>  </li></ul><ul><ul><li>Integração com centros de pesquisa, instituições de ensino e organizações privadas e públicas  </li></ul></ul><ul><li>  </li></ul><ul><ul><li>Fonte de informações para análise visando aprimoramento do ensino e evolução de pesquisas </li></ul></ul>
    5. 5.  
    6. 6. Cotidiano de um programador
    7. 7. Segunda-Feira <ul><li>10:00- Resolução de bugs no componente de CPF que é utilizado em 48 telas do sistema... </li></ul><ul><li>  </li></ul><ul><li>14:00 -Integração com uma biblioteca de terceiro para calculo financeiro OpenSource </li></ul><ul><li>  </li></ul><ul><li>16:00-Integração com código desenvolvido pelo programador jr da equipe. </li></ul>
    8. 8. Testes de software <ul><li>  </li></ul>
    9. 9. O que é mesmo TDD? <ul><li>É uma técnica de desenvolvimento de software que se baseia em ciclos de desenvolvimento de pequenos: </li></ul><ul><li>  </li></ul><ul><ul><li>Escreva um teste que defina uma funcionalidade desejada </li></ul></ul><ul><ul><li>Escreva o código que faz o teste passar </li></ul></ul><ul><ul><li>Refatore o código produzido </li></ul></ul>
    10. 10. Um pouco de história... <ul><ul><li>Design por contrato(DBC)‏ </li></ul></ul><ul><li>  </li></ul><ul><ul><li>Programação extrema(XP)  </li></ul></ul>
    11. 11. Testes automatizados <ul><ul><li>Documentação executável </li></ul></ul><ul><li>  </li></ul><ul><ul><li>Detecção de erros em tempo de programação </li></ul></ul><ul><li>  </li></ul><ul><ul><li>Confiança e garantia de que tudo funciona instantaneamente </li></ul></ul>
    12. 12. Testar antes de desenvolver? <ul><ul><li>Disciplina é liberdade! </li></ul></ul><ul><li>  </li></ul><ul><ul><li>Abandone o debug! </li></ul></ul><ul><li>  </li></ul><ul><ul><li>Pare de programar por coincidência </li></ul></ul><ul><li>  </li></ul><ul><ul><li>Aprender sobre os requisitos antes de escrever código </li></ul></ul><ul><li>  </li></ul><ul><ul><li>Ser o primeiro cliente do seu código </li></ul></ul><ul><li>  </li></ul><ul><ul><li>Garantir uma cobertura de código de 100% </li></ul></ul>
    13. 13. Metodologia R G R <ul><li>R -Escreva um teste para a nova funcionalidade desejada, </li></ul><ul><li>  </li></ul><ul><li>G -Escreva o código que faz o teste passar </li></ul><ul><li>  </li></ul><ul><li>R- Refatore o código </li></ul>
    14. 14. Bons testes unitários <ul><ul><li>Automáticos </li></ul></ul><ul><li>  </li></ul><ul><ul><li>Replicáveis </li></ul></ul><ul><li>  </li></ul><ul><ul><li>Independentes </li></ul></ul>
    15. 15. <ul><li>  </li></ul>
    16. 16. <ul><ul><li>Cobertura de código </li></ul></ul><ul><li>     JCover,NCover </li></ul><ul><li>  </li></ul><ul><ul><li>Frameworks de Teste  </li></ul></ul><ul><li>      XUnit,JUnit,NUnit,Visual Studio Test Tools,Rspec  </li></ul>
    17. 17. Como começar... <ul><ul><li>Tenha Fé! </li></ul></ul><ul><li>  </li></ul><ul><ul><li>Aplique TDD em pequenos módulos </li></ul></ul><ul><li>  </li></ul><ul><ul><li>Compare a taxa de bug com a taxa de cobertura </li></ul></ul>
    18. 18.   Testes não são &quot;bala de prata&quot; ! <ul><ul><li>Testes unitários não são de aceitação </li></ul></ul><ul><li>  </li></ul><ul><ul><li>Testes fazem apenas simulações </li></ul></ul>
    19. 19. Dojo do IST-Rio Desenvolvedores também treinam
    20. 20. Mais informações <ul><ul><li>Dojo Rio </li></ul></ul><ul><li>     http://groups.google.com/group/dojo-rio/topics?pli=1  </li></ul><ul><ul><li>Dojo DNA </li></ul></ul><ul><li>     http://groups.google.com/group/dotnetarchitects/topics </li></ul><ul><li>  </li></ul><ul><ul><li>http://improveit.com.br/xp/praticas/tdd  </li></ul></ul><ul><li>  </li></ul><ul><ul><li>http://www.extremeprogramming.org/ </li></ul></ul><ul><li>  </li></ul><ul><ul><li>http://en.wikipedia.org/wiki/XUnit </li></ul></ul><ul><li>  </li></ul><ul><li>  </li></ul>
    21. 21. <ul><li>&quot;Desenvolvedor que não testa é como um médico que não lava as mãos antes de fazer uma cirurgia&quot; </li></ul>
    22. 22. Contato <ul><li>Blogs: http://higorcesar.com.br/ </li></ul><ul><li>http://projetocomperio.org/blog </li></ul><ul><li>Email : </li></ul><ul><li>Higor- higor.crr@gmail.com </li></ul><ul><li>Renan - renan.cabral.baptista@gmail.com </li></ul><ul><li>Flavia - flaviafortes88@gmail.com </li></ul>

    ×