Introduz TDD, situando em relação aos diversos tipos de testes existentes.

1. Desenvolvimento Orientado por Testes
Daniel Capó Sobral

2. Ou não?

3. Taxonomias
• Funcional • Automático • Caixa Preta • Exploratório • Teste
• Não • Manual • Caixa Branca • Pré-definido Primeiro
Funcional • Caixa Cinza • Teste por
Último
Informação Momento de
Objeto de teste Execução Planejamento
sobre o sistema escrita
• Qualitativo • Estático • Estado • Verificação • TDD
• Quantitativo (tipos, • Interação • Validação • ATDD
provas) • BDD
• Dinâmico
Execução do Comportamento Contratado vs Técnica de
Resultado
código testado observado Desejado Escrita

4. Níveis
Escopo do Objeto Testado
Unit Testing
Integration Testing
System Testing
System Integration Testing

5. Níveis
Objetivo do Teste
Smoke Test
Regressão
Aceitação
Alpha
Beta

6. Não funcional
Performance Carga Usabilidade
Internacionalização
Segurança Destrutivo
e Localização
Compatibilidade Escalabilidade etc

7. “In test-driven development a developer creates automated unit
tests” – wikipedia

8. O que é TDD?
TDD é sobre como
escrever código de
aplicação. Teste Unitário
Automatizado
Teste
Primeiro
Técnica de
Desenvolvimento de
Software
TDD não é sobre
como escrever
testes!

9. Porque não fazer TDD?
Curva de Aprendizado Íngreme:
• Como escrever testes?
• Como escrever código testável?
• Como usar as ferramentas?
• Como se faz TDD?
Menor Produtividade
• Mais linhas de código
• Interrupções constantes
Maior Custo de Manutenção
• Mais código, mais manutenção
• Mudanças de arquitetura quebram testes!
• Mudanças de comportamento quebram testes!

10. Porque fazer TDD?
Menor Custo de Manutenção
• Confiança para efetuar mudanças
• Testes resguardam contra regressão
Maior Produtividade
• YAGNI! (You Ain’t Gonna Need It!) significa menos desperdício
• Menos tempo corrigindo bugs: estava funcionando a cinco minutos atrás!
Maior Qualidade
• Mais testes leva a menos bugs
• Testes unitários compreensivos resultam em baixo acoplamento

11. O que dizem os estudos?
• Inconclusivo
• Boa correlação, mas...
• Isolamento
• TDD ou outras práticas ágeis?
• TDD ou número de testes?
Maior • Mais testes levam a menos bugs? Confirmado.
Qualidade? • Curva de aprendizado íngreme dificulta grupos de controle
• Inconclusivo
• Conforme estudo, melhor, pior ou indiferente
Ea
Produtividade?

12. Famous last words.

13. Dificuldades
Que nome dar
aos testes?
Quanto se
O que não
testar de cada
testar?
vez?
O que testar?
Como
Onde entender
começar? porque o teste
falhou?
Como separar
uma unidade
de suas
dependências?
Fonte: Introducing BDD, Dan North

14. O que é um bom teste unitário?
Deve ser fácil de implementar.
Deve ser automatizável e reproduzível de forma confiável.
Qualquer um deve ser capaz de executá-lo, sem setups complicados.
Deve ser executável com um simples click.
Deve executar rapidamente.
Uma vez escrito, deve ser preservado para uso futuro.
Fonte: The Art of Unit Testing, Roy Osherove

15. Teste (automatizado) é Código
Arcabouço, Armação, Andaime
Removido ao fim da Mas software sem manutenção
Ajuda a construir
construção é software morto!
Atenção com
Manutenção Qualidade Legibilidade Refatoração Code Rot
Em outras palavras, deve receber as mesmas atenções que o código da
aplicação!

16. Removendo dependências: Fakes
Stubs
Mocks
Teste de
Teste de
estado
Interação
Como?
Asserções
Injeção de Dependências
Espelhamento

18. Três leis de TDD
Você não pode escrever código de aplicação exceto para
fazer passar um teste unitário.
Você não pode escrever código de teste mais do que o
necessário para falhar; falhar compilação também conta.
Você não pode escrever código de aplicação mais do que o
suficiente para fazer um teste unitário passar.
Segundo Robert Martin

19. Três fases de TDD
Vermelho
• Escrever código
de teste para
evidenciar
falha
Azul Verde
• Refactoring de • Escrever código
código de aplicação
(aplicação e para corrigir
testes) falha

20. Fluxo de TDD Não
Executa teste
Escrever teste Falhou?
Sim
Sim
Sim Não
Passou? Escrever aplicação
Executa teste Executa teste
Refatoração Sim Não
Passou?
(aplicação e testes)

22. Demonstração
Jogo de Boliche
 Regras:
 10 jogadas (frames)
 1 ou 2 arremessos por jogada (1ª à 9ª)
 2 ou 3 arremessos na 10ª jogada
 10 pinos
 1 ponto por pino derrubado
 Spare – 10 pinos derrubados em 2 arremessos
 10 pontos + próximo arremesso
 Strike – 10 pinos derrubados em 1 arremesso
 10 pontos + 2 próximos arremessos

23. Diagrama de Classe
 TODO

24. Escrevendo o código com TDD
 TODO

25. Discutir!

26. Referências
 Clean Coders (Robert Martin)
 Making Software: What Really Works, and Why We
Believe It (Andy Oram & Greg Wilson)
 The Art of Unit Testing: with Examples in .Net (Roy
Osherove)
 Introducing BDD (Dan North)
 Wikipedia (duh!)
 Test Driven Development: By Example (Kent Beck)