Como TDD pode influenciar na construção do seu Produto?

370 visualizações

Publicada em

Mostra as vantagens que o Test Driven Development trás para o design de sua aplicação, além do aprendizadoque ele trouxe no desenvolvimento do JTrace, uma biblioteca de computação gráfica.

Publicada em: Software
0 comentários
1 gostou
Estatísticas
Notas
  • Seja o primeiro a comentar

Sem downloads
Visualizações
Visualizações totais
370
No SlideShare
0
A partir de incorporações
0
Número de incorporações
2
Ações
Compartilhamentos
0
Downloads
4
Comentários
0
Gostaram
1
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Como TDD pode influenciar na construção do seu Produto?

  1. 1. Como TDD pode influenciar na construção do seu produto? Raphael Paiva
  2. 2. Raphael who? ● B.Sc. em Ciência da Computação pela UFRJ ● Coordenador técnico da equipe SIGA-UFRJ, integrante há 6 anos. ● Desenvolvimento e manutenção dos Sistemas de Gestão acadêmica e Acesso da UFRJ.
  3. 3. Raphael who? ● JPA, Seam, EJB, Selenium, TestNG, Puppet, CI, Infra, virtualização... You name it, we do it! ● Especialista em resolver bolas quadradas!
  4. 4. E… Entusiasta de TDD!
  5. 5. Mas chega de papo!
  6. 6. TDD: Testar código antes de escrever código?
  7. 7. Ok, mas...
  8. 8. Testar depois é ruim?
  9. 9. Não!
  10. 10. Testar antes garante mais cobertura do que testar depois?
  11. 11. Talvez...
  12. 12. Então que diferença faz testar antes?
  13. 13. Design!
  14. 14. “TDD doesn't drive good design. TDD gives you immediate feedback about what is likely to be a bad design.” -- Kent Beck
  15. 15. Pensar no código antes de escrever.
  16. 16. ● Como essa classe vai ser usada? ● Por quem essa classe será usada? ● Por que essa classe existe?
  17. 17. Design incremental! Baby Steps, nada de BDUF
  18. 18. “Simplicidade--a arte de maximizar a quantidade de trabalho não realizado--é essencial.” -- Manifesto Ágil
  19. 19. Case: JTrace Motor de geração de imagens por Ray Tracing https://github.com/raphaelpaiva/jtrace
  20. 20. Case: JTrace ● Ray Tracing: técnica utilizada nos filmes com CG -- Alto realismo
  21. 21. Case: JTrace ● Deve ser genérico e extensível ● Exigência de qualidade e facilidade de uso! ● Usado em trabalhos de alunos de graduação
  22. 22. O JTrace introduziu alguns desafios
  23. 23. Cada rodada demora entre vários segundos e muitos minutos.
  24. 24. Testar depois: Demorado e difícil. O output é uma imagem.
  25. 25. Erros podem acontecer em dezenas dentre milhões de pixels.
  26. 26. Como garantir qualidade neste cenário?
  27. 27. TDD ao resgate!
  28. 28. Design incremental ● Só implementar algo quando realmente for necessário. ● Generalizar quando necessário, arquitetura modular, baseada em delegação de responsabilidade. ● Unidades mínimas de código.
  29. 29. Por que?
  30. 30. Por que? ● Mais fácil e, talvez, o único modo são de testar. ● Mais unidades == mais testes == mais confiança
  31. 31. Resultados
  32. 32. Bugs capturados e resolvidos com extrema facilidade.
  33. 33. TDD como motivador
  34. 34. Interface enxuta e genérica API composta basicamente de 5 conceitos. Iluminação, Câmeras, Objetos Geométricos, Primitivas e Listeners.
  35. 35. Fácil de usar! Obtivemos ótimas implementações de trabalhos e pouquíssimas dúvidas.
  36. 36. Os testes geraram exemplos úteis no aprendizado da API!
  37. 37. 0 bugs reportados!
  38. 38. Sucesso == aprendizado
  39. 39. Cobertura por cobertura? Até quando vale o esforço de aumentar a cobertura de testes?
  40. 40. O que testar? 50,9% ou 81,3%?
  41. 41. TDD Funciona só para testes unitários?
  42. 42. NÃO, embora muita gente pense que sim... Mocks everywhere?
  43. 43. Testar antes: verificação ou design?
  44. 44. Ambos!
  45. 45. Dúvidas? Obrigado! @raphaelmacoli raphaeldpaiva@gmail.com

×