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.

1. TDD e Refactoring
André Luís Pitombeira
Saturday, May 25, 13

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

5. Programação
• Primeira parte
• Test-Driven Development (TDD)
• Segunda parte
• Refactoring
Saturday, May 25, 13

6. Test-Driven Development (Parte I)
Saturday, May 25, 13

7. Agenda
• Motivação
• Famílias e tipos de testes
• Teste unitário
• Test-Driven Development
• Exercício de fixação
Saturday, May 25, 13

8. O problema
Barato Rápido
Bom
Saturday, May 25, 13

9. No silver bullet!
Saturday, May 25, 13

10. Porém, com testes...
• Um pouco mais rápido
• Um pouco mais barato
• Um pouco melhor
Saturday, May 25, 13

11. Rápido
0
250
500
750
1000
Projeto Implementação QA Post-release
Tempo gasto para resolver bugs
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

13. Melhor
• Desenvolvimento tradicional
• Instintivo
• Difícil de mensurar
• TDD
• Indicativo
• Mensurável
• Testável
Saturday, May 25, 13

14. Então, a solução é testar
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

28. hands-on!
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

30. Ciclo do desenvolvimento com TDD
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

39. hands-on!
Saturday, May 25, 13

40. Tópico para discussão
• Deveríamos testar métodos privados?
• Sempre devemos usar TDD?
Saturday, May 25, 13

41. Perguntas?
Saturday, May 25, 13

42. Obrigado!
Saturday, May 25, 13

43. Test-Driven Development (Parte II)
Saturday, May 25, 13

44. Agenda
• Revisão
• JUnit
• Mock
• Padrões de TDD
• Exercícios
Saturday, May 25, 13

45. Cenas dos capítulos anteriores...
Saturday, May 25, 13

46. Cenas dos capítulos anteriores...
Saturday, May 25, 13

47. JUnit
Saturday, May 25, 13

48. JUnit
• Annotations
• @Test
• @Before e @After
• @BeforeClass e @AfterClass
• @Test(expected = ArithmeticException.class)
• @Ignore
• @Test(timeout = 1000)
Saturday, May 25, 13

49. JUnit
Assertions do JUnit
Saturday, May 25, 13

50. Mock
Saturday, May 25, 13

51. Exemplo de mock (Simples)
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

56. Saturday, May 25, 13

57. Saturday, May 25, 13

58. Saturday, May 25, 13

59. Saturday, May 25, 13

60. Test-Driven Development (Parte III)
Saturday, May 25, 13

61. Agenda
• Exercício
Saturday, May 25, 13

62. Dinheiro Multi-Moeda
Instrumento Ações Preço Total
Apple 1000 25 USD 25000 USD
Google 400 150 CHF 60000 CHF
TotalTotalTotal 65000 USD
De Para Taxa
CHF USD 1,5
Saturday, May 25, 13

63. Saturday, May 25, 13

64. Saturday, May 25, 13

65. Refactoring (Parte I)
Saturday, May 25, 13

66. Agenda
• Conceitos básicos
• Exemplo
Saturday, May 25, 13

67. O que é refactoring?
Saturday, May 25, 13

68. Saturday, May 25, 13

69. hands-on!
Saturday, May 25, 13

70. Saturday, May 25, 13

71. Saturday, May 25, 13

72. Refactoring (Parte II)
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

79. “Mau cheiro” no código(Não é isso)
Saturday, May 25, 13

80. “Mau cheiro” no código
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

82. Técnicas de Refactoring
Saturday, May 25, 13

83. hands-on!
Saturday, May 25, 13

84. Saturday, May 25, 13

85. Saturday, May 25, 13