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!

Dúvidas?Obrigado!

@raphaelmacoli

raphaeldpaiva@gmail.com