Embed Size (px)
DESCRIPTION
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.
Citation preview
Como TDD pode influenciar na construção do seu produto?
Raphael Paiva
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.
Raphael who?
● JPA, Seam, EJB, Selenium, TestNG, Puppet, CI, Infra, virtualização... You name it, we do it!
● Especialista em resolver bolas quadradas!
E… Entusiasta de TDD!
Mas chega de papo!
TDD: Testar código antes de escrever código?
Ok, mas...
Testar depois é ruim?
Não!
Testar antes garante mais cobertura do que testar depois?
Talvez...
Então que diferença faz testar antes?
Design!
“TDD doesn't drive good design. TDD gives you immediate feedback about what is likely
to be a bad design.” -- Kent Beck
Pensar no código antes de escrever.
● Como essa classe vai ser usada?● Por quem essa classe será
usada?● Por que essa classe existe?
Design incremental!Baby Steps, nada de BDUF
“Simplicidade--a arte de maximizar a quantidade de trabalho não realizado--é
essencial.” -- Manifesto Ágil
Case: JTraceMotor de geração de imagens por Ray
Tracing
https://github.com/raphaelpaiva/jtrace
● Ray Tracing: técnica utilizada nos filmes com CG -- Alto realismo
Case: JTrace
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
O JTrace introduziu alguns desafios
Cada rodada demora entre vários segundos e muitos minutos.
Testar depois: Demorado e difícil.O output é uma imagem.
Erros podem acontecer em dezenas dentre milhões de pixels.
Como garantir qualidade neste cenário?
TDD ao resgate!
● 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.
Design incremental
Por que?
● Mais fácil e, talvez, o único modo são de testar.
● Mais unidades == mais testes == mais confiança
Por que?
Resultados
Bugs capturados e resolvidos com extrema facilidade.
TDD como motivador
Interface enxuta e genérica
API composta basicamente de 5 conceitos.Iluminação, Câmeras, Objetos Geométricos, Primitivas e Listeners.
Fácil de usar!
Obtivemos ótimas implementações de trabalhos e pouquíssimas dúvidas.
Os testes geraram exemplos úteis no aprendizado da API!
0 bugs reportados!
Sucesso == aprendizado
Cobertura por cobertura? Até quando vale o esforço de aumentar a
cobertura de testes?
50,9% ou 81,3%?
O que testar?
TDD Funciona só para testes unitários?
NÃO, embora muita gente pense que sim...
Mocks everywhere?
Testar antes: verificação ou design?
Ambos!
