o poder do tdd
TRANSCRIPT
O Poder do TDDRafael Queiroz
Rafael Queiroz
Aprendi fazendo TDD
Teste de unidade TDD DDD Design Patterns Refatoração Clean Code SOLID
Compreendi fazendo TDD
Confiança Feedback curto Ritmo Lean
Kaizen Eliminar disperdícios Simplicidade
Olhar só para o presente
Compreendi fazendo TDD
Arquitetura emergente Arquitetura aderente ao negócio, não o
contrário Relação entre pequenas mudanças cotidianas
e grandes resultados
Test Driven Development
Desenvolvimento guiado por testeDesenvolvimento orientado a teste
Teste?
Testar: verboTeste: substantivoTeste automatizado
Que teste?
Unit
Teste UnitárioTeste de Unidade
Unidade
Método - Kent BeckUnidade de trabalho: de um método até múltiplas classes – Roy Osherove
Test Driven Development
Desenvolvimento guiado por teste automatizado de unidadeProblem Driven DesignArquitetura Guiada por Problema
Objetivo
Obter feedback rápido das decisões - Kent Beck“Código limpo que funciona” - Ron Jeffries
Testes
“Toda linha de código que você escreve deve estar testada, e Ponto Final.”
Uncle Bob
Estresse
Execução de Testes
Aspiral da morte do “sem tempo para testar”.
Importância dos testes
Estresse
Execução de TestesExecução de Testes Automáticos
Como mudar?
Coragem
Hesitante Querer comunicar menos Afastar do feedback Mal-humorado
Ciclo TDD
Adicione um pequeno teste
Rode os testes e veja falhar
Ciclo TDD
Faça a mudança mais simples para passar
Rode os testes e veja ser bem-sucedido
Ciclo TDD
Refatore para remover duplicação
Rode os testes e veja ser bem-sucedido
Impacto
Código vivo Devemos escrever nossos testes Ambiente rápido Código testável, altamente coeso e
fracamente acoplado A garantia de qualidade passa de reativo para
pró-ativo
Lista de testes
Liste os testes que precisa para terminar uma tarefa Escolha o que mais pode te ensinar algo, que você
confia em implementar e aplique o ciclo TDD um por vez
Ao codificar, adicione os testes emergente no fim da lista
Ao codificar, crie uma lista de maus cheiros de código” Crie todos os testes que consiga imaginar
Nomeando testes
Unidade de Trabalho Cenário Comportamento esperado
Retorno de valor Exceção Modificação de estado Requisição de outro sistema
Modelo: UnidadeDeTrabalho_Cenario_ComportamentoEsperadoExemplo: SalvarUsuario_SemCpf_LancarExcecao
Propriedades de um bom teste
Deve ser relevante amanhã Rodar com um apertar de botão Deve rodar rápido Deve ter resultados consistentes Deve ter controle total sobre a unidade testada Ao falhar, deve ser rápido de detectar e
determinar onde está o problema
Testes isolados
Um teste não deve afetar o outro Deve ser independente
Dados de teste
Fácil de ler Fáceis de seguir Se o sistema manipular várias entradas, você
dever ter os mesmos testes para a mesma unidade
Um dado não deve significar mais que uma coisa
Dados realistas
Dados evidentes
Não utilizar constantes nos testes Deixar claro a relação das entradas e da
asserção
Asserção Primeiro
Escrever um teste é difícil Escreva as asserções primeiro
Barra vermelha
Um só passo Aprendizado Outro teste Regressão Pausa
Barra verde
Fazer de conta Triangular Implementação óbvia
Padrões de teste
Teste filho Mock Modelo de testes de acidente Teste quebrado Código limpo
O que devemos testar?
Condições Laços Operações Polimorfismo
Mantra
