Desenvolvimento Guiado por Testes Test-Driven Development (TDD) Guilherme Chapiewski http://gc.blog.br
O que é TDD?
Regras fundamentais do TDD: <ul><li>Escreva o teste da implementação ANTES de escrevê-la </li></ul><ul><li>Escreva somente...
Ciclo do desenvolvimento com TDD: <ul><li>Criar um teste </li></ul><ul><li>Executar todos os testes da aplicação para ver ...
Motivação
Motivações para adoção de TDD: <ul><li>Design pouco testável </li></ul><ul><li>Baixa cobertura de testes unitários </li></...
Conceitos
Tipos de testes: <ul><li>Testes Unitários </li></ul><ul><li>Testes de Integração </li></ul><ul><li>Testes de Aceitação </l...
1. Testes Unitários: <ul><li>Testam apenas um componente do sistema </li></ul><ul><li>Todos os outros componentes são simu...
2. Testes de Integração: <ul><li>Testam a integração entre componentes </li></ul><ul><li>Envolvem dois ou mais componentes...
3. Testes de Aceitação: <ul><li>Testam uma história, funcionalidade ou caso de uso </li></ul><ul><li>Envolvem vários compo...
Demonstração
1. Definção da interface:
2. Criação do teste:
3. Execução do teste: (deve falhar pois sequer há implementação)‏
4. Criação da classe de implementação: (somente o esqueleto da classe retornando sempre o mesmo resultado)‏
5. Execução do teste: (falhou porque a implementação desenvolvida sempre retorna FALSE)‏
6. Programação do método:
7. Execução do teste: (teste passou: 100% de certeza que o código funciona!!!)‏
8. Refactoring:
9. Execução do teste: (teste falhou por distração do programador: não verificou se cep é nulo!!!)‏
10. Corrigindo o refactor:
11. Execução do teste: (teste passou: temos 100% de certeza que o código CONTINUA funcionando e que nenhum componente que ...
Consequências
Consequências: <ul><li>Suite de regressão </li></ul><ul><ul><ul><li>Testes completos sendo executados no build: aplicação ...
Consequências: <ul><li>Código mais testável </li></ul><ul><ul><ul><li>Estimula um design melhor </li></ul></ul></ul><ul><u...
Consequências: <ul><li>Integração contínua </li></ul>
Consequências: <ul><li>Integração contínua </li></ul>
Conclusões
Conclusões: <ul><li>Colabora para o aumento da qualidade dos sistemas </li></ul><ul><li>Desenvolvedores ficam mais corajos...
Conclusões: <ul><li>Demora mais? </li></ul>
Conclusões: <ul><li>Demora mais? </li></ul><ul><ul><ul><li>No início é necessário escrever muitos testes </li></ul></ul></...
Leitura complemetar: <ul><li>Introduction to TDD:  http://www.agiledata.org/essays/tdd.html </li></ul><ul><li>Desenvolvime...
Obrigado! Guilherme Chapiewski http://gc.blog.br
Próximos SlideShares
Carregando em…5
×

Desenvolvimento Guiado Por Testes

6.953 visualizações

Publicada em

Apresentação sobre Desenvolvimento Guiado por Testes apresentada no RioJUG em Junho de 2007.

Publicada em: Tecnologia
0 comentários
12 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

Sem downloads
Visualizações
Visualizações totais
6.953
No SlideShare
0
A partir de incorporações
0
Número de incorporações
867
Ações
Compartilhamentos
0
Downloads
280
Comentários
0
Gostaram
12
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Desenvolvimento Guiado Por Testes

  1. 1. Desenvolvimento Guiado por Testes Test-Driven Development (TDD) Guilherme Chapiewski http://gc.blog.br
  2. 2. O que é TDD?
  3. 3. Regras fundamentais do TDD: <ul><li>Escreva o teste da implementação ANTES de escrevê-la </li></ul><ul><li>Escreva somente código suficiente para o teste passar e nada além disso </li></ul><ul><li>Escreva testes pequenos: teste a menor quantidade possível de código de cada vez </li></ul><ul><li>Escreva testes muito rápidos: não devem demorar mais do que alguns segundos para serem executados </li></ul>
  4. 4. Ciclo do desenvolvimento com TDD: <ul><li>Criar um teste </li></ul><ul><li>Executar todos os testes da aplicação para ver o novo teste falhar </li></ul><ul><li>Escrever a implementação testada </li></ul><ul><li>Executar os testes para ver se todos passarão </li></ul><ul><li>Refactoring </li></ul><ul><li>Executar os testes novamente para garantir que eles continuam passando </li></ul>
  5. 5. Motivação
  6. 6. Motivações para adoção de TDD: <ul><li>Design pouco testável </li></ul><ul><li>Baixa cobertura de testes unitários </li></ul><ul><li>Necessidade de “levantar” todo o ambiente para desenvolver e testar </li></ul><ul><li>Necessidade de manter compatibilidade retroativa </li></ul><ul><li>Insegurança ao modificar base de código </li></ul>
  7. 7. Conceitos
  8. 8. Tipos de testes: <ul><li>Testes Unitários </li></ul><ul><li>Testes de Integração </li></ul><ul><li>Testes de Aceitação </li></ul>
  9. 9. 1. Testes Unitários: <ul><li>Testam apenas um componente do sistema </li></ul><ul><li>Todos os outros componentes são simulados (mock objects)‏ </li></ul><ul><li>Ferramentas: JUnit, JMock/EasyMock </li></ul><ul><li>Fundamental para a prática do TDD! </li></ul>
  10. 10. 2. Testes de Integração: <ul><li>Testam a integração entre componentes </li></ul><ul><li>Envolvem dois ou mais componentes (classes+SGBD, classes+SGBD+Fast, etc.)‏ </li></ul><ul><li>Ferramentas: JUnit, DBUnit, HSQLDB, Fit </li></ul><ul><li>Normalmente não utilizado em TDD </li></ul>
  11. 11. 3. Testes de Aceitação: <ul><li>Testam uma história, funcionalidade ou caso de uso </li></ul><ul><li>Envolvem vários componentes do sistema </li></ul><ul><li>Ferramenta : JUnit, Selenium </li></ul><ul><li>Pode ser utilizado em TDD </li></ul>
  12. 12. Demonstração
  13. 13. 1. Definção da interface:
  14. 14. 2. Criação do teste:
  15. 15. 3. Execução do teste: (deve falhar pois sequer há implementação)‏
  16. 16. 4. Criação da classe de implementação: (somente o esqueleto da classe retornando sempre o mesmo resultado)‏
  17. 17. 5. Execução do teste: (falhou porque a implementação desenvolvida sempre retorna FALSE)‏
  18. 18. 6. Programação do método:
  19. 19. 7. Execução do teste: (teste passou: 100% de certeza que o código funciona!!!)‏
  20. 20. 8. Refactoring:
  21. 21. 9. Execução do teste: (teste falhou por distração do programador: não verificou se cep é nulo!!!)‏
  22. 22. 10. Corrigindo o refactor:
  23. 23. 11. Execução do teste: (teste passou: temos 100% de certeza que o código CONTINUA funcionando e que nenhum componente que depende deste código quebrou após o refactor)‏
  24. 24. Consequências
  25. 25. Consequências: <ul><li>Suite de regressão </li></ul><ul><ul><ul><li>Testes completos sendo executados no build: aplicação não sobe para produção se não passar no teste de regressão </li></ul></ul></ul><ul><li>Testes também pode ser feitos na IDE </li></ul><ul><ul><ul><li>Não há necessidade de deploy da aplicação para execução dos teste s </li></ul></ul></ul><ul><ul><ul><li>Bugs são encontrados com maior facilidade e corrigidos com maior velocidade </li></ul></ul></ul><ul><li>Bugs comprovados por testes unitários </li></ul>
  26. 26. Consequências: <ul><li>Código mais testável </li></ul><ul><ul><ul><li>Estimula um design melhor </li></ul></ul></ul><ul><ul><ul><li>Força que os designs antigos que são pouco testáveis sejam refatorados </li></ul></ul></ul><ul><li>Facilita o refactoring </li></ul><ul><li>Evita “overdesign” </li></ul><ul><ul><ul><li>Só se escreve código suficiente para o teste passar </li></ul></ul></ul><ul><ul><ul><li>Evita que o desenvolvedor fique tentando adivinhar o futuro </li></ul></ul></ul><ul><li>Colabora com a documentação </li></ul>
  27. 27. Consequências: <ul><li>Integração contínua </li></ul>
  28. 28. Consequências: <ul><li>Integração contínua </li></ul>
  29. 29. Conclusões
  30. 30. Conclusões: <ul><li>Colabora para o aumento da qualidade dos sistemas </li></ul><ul><li>Desenvolvedores ficam mais corajosos e confiantes ao programar! </li></ul><ul><li>Software cresce de forma ordenada e com qualidade de design </li></ul><ul><li>Software se adapta com mais facilidade a mudanças </li></ul>
  31. 31. Conclusões: <ul><li>Demora mais? </li></ul>
  32. 32. Conclusões: <ul><li>Demora mais? </li></ul><ul><ul><ul><li>No início é necessário escrever muitos testes </li></ul></ul></ul><ul><ul><ul><li>Depois da inércia a suite de regressão está pronta e escrevem-se menos testes </li></ul></ul></ul><ul><ul><ul><li>Certeza de que a implementação está funcionando </li></ul></ul></ul><ul><ul><ul><li>Maioria dos bugs encontrados em tempo de desenvolvimento </li></ul></ul></ul><ul><ul><ul><li>Bugs de produção são encontrados e corrigidos com muito mais velocidade </li></ul></ul></ul><ul><ul><li>Então no fim das contas demora-se muito menos tempo e com muito mais qualidade! </li></ul></ul>
  33. 33. Leitura complemetar: <ul><li>Introduction to TDD: http://www.agiledata.org/essays/tdd.html </li></ul><ul><li>Desenvolvimento Orientado a Testes: http://www.improveit.com.br/xp/praticas/tdd </li></ul><ul><li>Screencast TDD em ação: http://dojofloripa.wordpress.com/2007/05/21/screencast-tdd-em- acao/ </li></ul><ul><li>Improve your unit tests by replacing your collaborators with mock objects: http://www.opensourcetutorials.com/tutorials/Server-Side-Coding/Java/java-unit-testing-with-mock-objects </li></ul><ul><li>Behaviour-Driven Development: http://behaviour-driven.org/ </li></ul>
  34. 34. Obrigado! Guilherme Chapiewski http://gc.blog.br

×