O documento discute como o TDD (Test Driven Development) pode influenciar positivamente na construção de produtos, levando a um design mais sólido e incrementais. O TDD fornece feedback imediato sobre designs ruins e incentiva pensar no código antes de escrevê-lo. Isso é ilustrado pelo caso do motor de renderização de imagens JTrace, onde o TDD permitiu que erros fossem capturados facilmente e resultou em uma interface enxuta e fácil de usar.

1. Como TDD pode influenciar na
construção do seu produto?
Raphael Paiva

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. Raphael who?
● JPA, Seam, EJB, Selenium, TestNG, Puppet, CI, Infra,
virtualização... You name it, we do it!
● Especialista em resolver bolas quadradas!

4. E… Entusiasta de TDD!

5. Mas chega de papo!

6. TDD: Testar código antes de
escrever código?

8. Ok, mas...

9. Testar depois é ruim?

10. Não!

11. Testar antes garante mais cobertura
do que testar depois?

12. Talvez...

13. Então que diferença faz testar
antes?

14. Design!

15. “TDD doesn't drive good design. TDD gives
you immediate feedback about what is likely
to be a bad design.”
-- Kent Beck

16. Pensar no código antes de escrever.

17. ● Como essa classe vai ser usada?
● Por quem essa classe será
usada?
● Por que essa classe existe?

18. Design incremental!
Baby Steps, nada de BDUF

19. “Simplicidade--a arte de maximizar a
quantidade de trabalho não realizado--é
essencial.”
-- Manifesto Ágil

20. Case: JTrace
Motor de geração de imagens por Ray
Tracing
https://github.com/raphaelpaiva/jtrace

21. Case: JTrace
● Ray Tracing: técnica utilizada nos filmes
com CG -- Alto realismo

22. 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

23. O JTrace introduziu alguns desafios

24. Cada rodada demora entre vários
segundos e muitos minutos.

25. Testar depois: Demorado e difícil.
O output é uma imagem.

26. Erros podem acontecer em dezenas
dentre milhões de pixels.

27. Como garantir qualidade neste
cenário?

29. TDD ao resgate!

30. 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.

31. Por que?

32. Por que?
● Mais fácil e, talvez, o único modo são de
testar.
● Mais unidades == mais testes == mais
confiança

33. Resultados

34. Bugs capturados e resolvidos com
extrema facilidade.

35. TDD como motivador

36. Interface enxuta e genérica
API composta basicamente de 5 conceitos.
Iluminação, Câmeras, Objetos Geométricos,
Primitivas e Listeners.

37. Fácil de usar!
Obtivemos ótimas implementações de trabalhos e
pouquíssimas dúvidas.

38. Os testes geraram exemplos úteis no
aprendizado da API!

39. 0 bugs reportados!

40. Sucesso == aprendizado

41. Cobertura por cobertura? Até
quando vale o esforço de aumentar a
cobertura de testes?

42. O que testar?
50,9% ou 81,3%?

43. TDD Funciona só para testes
unitários?

44. NÃO, embora muita gente pense
que sim...
Mocks everywhere?

45. Testar antes: verificação ou design?

46. Ambos!

47. Dúvidas?
Obrigado!
@raphaelmacoli
raphaeldpaiva@gmail.com