O documento apresenta um curso sobre TDD (Test-Driven Development) e Refactoring. O curso tem como objetivos definir os principais conceitos relacionados a TDD e Refactoring, mostrar boas práticas de programação e design de sistemas, e demonstrar o uso de ferramentas. A programação será dividida em TDD e Refactoring, abordando conceitos, benefícios, técnicas e exercícios práticos de cada tema.
2. Quem sou eu?
• Bacharel em Sistemas de Informação (UFC/
Quixadá)
• Bacharel em Administração de Empresas (FCRS)
• Desenvolvedor de Software do lsbd
Saturday, May 25, 13
3. Quem são vocês?
• Respondam estas três perguntas
• Qual o seu nome?
• O que você faz da vida?
• O que você espera deste curso?
Saturday, May 25, 13
4. Objetivos
• Definir os principais conceitos relacionados ao
TDD e Refactoring
• Mostrar boas práticas de programação e design de
sistemas
• Demonstrar o uso de algumas ferramentas
Saturday, May 25, 13
12. Barato
• Bugs são descobertos nas fases iniciais do
desenvolvimento
• Custo para resolver bug = Número de bugs /
Custo por bug resolvido
• Custo dos testes = Número de features /
Complexidade das features
Saturday, May 25, 13
15. Mas por que os desenvolvedores
deveriam escrever testes?
• Respostas comuns
• Deixa os testes para o QA
• Desenvolvedores são muito ocupados
• Desenvolvedores não sabem como testar
• Nós não temos bugs
• Desenvolvedores não são adequados para testar
o código
Saturday, May 25, 13
16. Os desenvolvedores deveriam
considerar isto...
• Como os desenvolvedores vão saber que estão
fazendo software de qualidade sem os testes?
• Testes são uma ferramenta para ajudar os
desenvolvedores a contribuírem para qualidade
• Testes ajudam a dar perquenos passos e receber
feedback constante
• Testes ajudam a manter o foco sobre
mensuráveis resultados de desenvolvimento
Saturday, May 25, 13
17. Panorama da indústria
• Principais problemas relatados na adoção de
testes pela indústria
• Aumenta o tempo de desenvolvimento
• Experiência ou habilidade insuficiente
• Insuficiente design
• Insuficiente aderência ao TDD
• Falta de ferramentas
Saturday, May 25, 13
18. O que é um teste de software?
Saturday, May 25, 13
19. “O teste de software é a
investigação do software a fim
de fornecer informações sobre
sua qualidade em relação ao
contexto em que ele deve
operar. Isto inclui o processo de
utilizar o produto para
encontrar seus defeitos.”
Wikipedia
Saturday, May 25, 13
20. O que é qualidade de software?
Saturday, May 25, 13
21. “A qualidade de software é uma
área de conhecimento da
engenharia de software que
objetiva garantir a qualidade do
software através da definição e
normatização de processos de
desenvolvimento.” Wikipedia
Saturday, May 25, 13
22. Tipos de teste (Alguns)
• Teste funcional
• Teste de usabilidade
• Teste de stress
• Teste de aceitação
• Teste de regressão
• Teste de configuração
• Teste unitário
Saturday, May 25, 13
23. Famílias de Teste
• XUnit (JUnit, PyUnit, JsUnit)
• “assert”
• TAP (libtap)
• “ok” ou “is”
Saturday, May 25, 13
24. Teste unitário
“Teste unitário é o método pelo qual unidades de
código são testadas para verificar se estas estão aptas
para o uso. Uma unidade é a menor parte testável de
uma aplicação.” Wikepedia
Saturday, May 25, 13
25. Por que teste unitário?
• Debugar é um processo que consume tempo
• Quando novas funcionalidades são adicionadas,
como assegurar que as antigas não quebraram?
• Ver a classe em ação
• Medida de qualidade de software
Saturday, May 25, 13
26. Teste unitário é bom se...
• É realmente automático
• Testa tudo que é provável quebrar
• Deve ser independente de ambiente e de outros
testes
• Deve ser repetitivo e mostrar sempre o mesmo
resultado toda vez que executar
• O teste deve ser claro
Saturday, May 25, 13
27. Exemplo de teste unitário
public void marriageIsSimmetric(){
Customer alice = new Customer();
Customer bob = new Customer();
bob.marry(alice);
assertTrue(bob.ismariedTo(alice));
assertTrue(alice.ismariedTo(bob));
}
Saturday, May 25, 13
29. O que é TDD?
• Uma técnica iterativa para desenvolver software
• Escreva primeiro um teste que falha(ou até mesmo
não compile), antes de escrever uma nova
funcionalidade
• O objetivo do TDD é especificação e não validação
• Uma prática para evoluir o código eficientemente
Saturday, May 25, 13
31. Regras fundamentais do TDD
• Escreva somente o código suficiente para o teste
passar
• Escreva testes pequenos
• Escreva testes muito rápidos
Saturday, May 25, 13
32. Motivações para o uso do TDD
• Design pouco testável
• Baixa cobertura de testes unitários
• Necessidade de levantar todo o ambiente para
poder testar
• Necessidade de manter compatibilidade retroativa
• Insegurança ao modificar a base de código
Saturday, May 25, 13
33. Benefícios em usar TDD
• Suíte de regressão
• Testes são feitos na IDE
• Bugs comprovados por testes unitários
• Código mais testável
• Facilita o refactoring
• Evita o “overdesign”
• Colabora com a documentação
Saturday, May 25, 13
34. Ponderações sobre o uso do TDD
• Demora mais?
• No início é necessário escrever muitos testes
• Suite de regressão
• Certeza de que a implementação está rodando
• Maioria dos bugs encontrados em tempo de
desenvolvimento
• Bugs corrigidos mais rápidos
Saturday, May 25, 13
35. TDD é código que funciona
• Previsível
• Aprendizagem
• Confiança
• Documentação
• Proteção
• Teste suite automatizado
Saturday, May 25, 13
36. Quando devo parar?
• O sistema funciona
• O código comunica o que está fazendo
• Não existe código duplicado
• O sistema deveria ter a menor quantidade possível
de classes e métodos
Saturday, May 25, 13
37. TDD é sobre design, não sobre testes
• Use TDD para produzir algo simples que funcione
(KISS)
• Guie o design do software através dos testes
• Foque sobre escrever soluções simples para os
requisitos
• Escreva somente código para o teste passar
• Remova código duplicado (DRY)
Saturday, May 25, 13
38. TDD vs UML
• Análise prévia do problema
• Reutilização de código
• Linguagem unificada para especificação de
sistemas
• Aumento na qualidade
• Ferramenta de aprendizado
• Facilidade de manutenção
Saturday, May 25, 13
52. Exemplo de mock (Um pouco mais
complexo)
Saturday, May 25, 13
53. Padrões de TDD
• O que queremos testar?
• Quando testamos?
• Como escolhemos que lógica testar?
• Como escolhemos quais dados testar?
Saturday, May 25, 13
54. Padrões de TDD
• Teste (substantivo)
• Teste isolado
• Lista de testes
• Teste primeiro
• Defina uma asserção primeiro
• Dados de teste
• Dados evidentes
Saturday, May 25, 13
55. Exercícios de TDD
• Valida RG
• Valida Chassi
• Valida CPF
Saturday, May 25, 13
73. Agenda
• Conceitos básicos
• Motivos para refatorar
• Princípios de design de software
• “Mau cheiro”
• Ciclo do refactoring
• Técnicas de refactoring
• Exercício
Saturday, May 25, 13
74. • Refactoring(substantivo) - Mudança feita na
estrutura interna do software para fazê-lo fácil de
ler e barato de mudar sem alterar seu
comportamento
• Refactor(verbo) - Reestruturar o software através
de uma série de refactorings sem alterar seu
compotamento
Saturday, May 25, 13
75. O propósito do refactoring é fazer o
software fácil de entender e modificar
Saturday, May 25, 13
76. Por que você deveria refatorar?
Saturday, May 25, 13
77. Alguns porquês...
• Melhorar o design do software
• Fazer o software mais fácil de entender
• Encontrar bugs
• Escrever código mais rapidamente
Saturday, May 25, 13
78. Princípios de design de software
• Princípio da responsabilidade única
• Princípio aberto fechado
• Princípio da substituição de Liskov
• Princípio da injeção de dependência
• Princípio de segregação de interface
Saturday, May 25, 13
81. O ciclo do refactoring
• O escolha o “mau cheiro”
• Selecione uma refatoração
• Aplique a refatoração
• Execute todos os testes
Saturday, May 25, 13