![Situação problema ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (9)
Similaire à Projeto Comperio TDD
Similaire à Projeto Comperio TDD (20)
Projeto Comperio TDD
- 1. Projeto Comperio e Desenvolvimento dirigido por testes(TDD) Alunos: Flavia Fortes, Higor Ramos e Renan Cabral
- 6. Cotidiano de um programador
- 19. Dojo do IST-Rio Desenvolvedores também treinam
Notes de l'éditeur
- - 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