• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Introdução a TDD
 

Introdução a TDD

on

  • 760 views

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

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

Statistics

Views

Total Views
760
Views on SlideShare
755
Embed Views
5

Actions

Likes
0
Downloads
17
Comments
0

2 Embeds 5

http://www.linkedin.com 3
https://www.linkedin.com 2

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

CC Attribution License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Introdução a TDD Introdução a TDD Presentation Transcript

    • Desenvolvimento Orientado por Testes Daniel Capó Sobral
    • Ou não?
    • 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 deObjeto 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 deResultado código testado observado Desejado Escrita
    • NíveisEscopo do Objeto TestadoUnit Testing Integration Testing System Testing System Integration Testing
    • NíveisObjetivo do Teste Smoke Test Regressão Aceitação Alpha Beta
    • Não funcional Performance Carga Usabilidade Internacionalização Segurança Destrutivo e Localização Compatibilidade Escalabilidade etc
    • “In test-driven development a developer creates automated unittests” – wikipedia
    • O que é TDD?TDD é sobre comoescrever código deaplicação. Teste Unitário Automatizado Teste Primeiro Técnica de Desenvolvimento de Software TDD não é sobre como escrever testes!
    • 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!
    • 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
    • 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 EaProdutividade?
    • Famous last words.
    • 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
    • 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
    • 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!
    • Removendo dependências: FakesStubs Mocks Teste de Teste de estado Interação Como? Asserções Injeção de Dependências Espelhamento
    • 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
    • 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
    • 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)
    • DemonstraçãoJogo 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
    • Diagrama de Classe TODO
    • Escrevendo o código com TDD TODO
    • Discutir!
    • 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)