Baixado 22 vezes
Carregado porDaniel Sobral
Introdução a TDD
O documento discute técnicas de teste de software, incluindo desenvolvimento orientado a testes (TDD). Apresenta diferentes tipos de testes, como unitário, de integração e de sistema, além de abordar tópicos como planejamento, execução e resultados de testes. Também explica princípios e benefícios do TDD, como aumento da qualidade e produtividade.
Introdução a TDD
- 1. Desenvolvimento Orientado porTestes Daniel Capó Sobral
- 2.
- 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 ObjetoTestado 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 developmenta 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 fazerTDD? 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 dizemos 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.
- 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 deTDD 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 deTDD 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.
- 24. Escrevendo o códigocom TDD TODO
- 25.
- 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)