Aplicando eXtreming Programing ao cenário do Borland ALM - BorCon 2003
Coding Dojo e TDD: aprendizado, prática e discussão de código
1. Coding Dojo e TDD
Alex Tercete Matos
11 de setembro de 2009
2. Antes de começar. . .
Grupo de Gestão do Conhecimento Coding Dojo e Test-driven Development – 2 / 26
3. Quem sou eu?
• CEFET/RJ
− 9o período, Engenharia de Controle e Automação
• Chemtech
− 11 meses, Projeto Planta Piloto de Biorreator
• Interesses
− Software Livre, ÆÍ»Ä ÒÙÜ , ÈÝØ ÓÒ
− Scrum, Extreme Programming (XP), Test-driven
Development (TDD)
Grupo de Gestão do Conhecimento Coding Dojo e Test-driven Development – 3 / 26
4. Quem sou eu?
• CEFET/RJ
− 9o período, Engenharia de Controle e Automação
• Chemtech
− 11 meses, Projeto Planta Piloto de Biorreator
• Interesses
− Software Livre, ÆÍ»Ä ÒÙÜ, ÈÝØ ÓÒ
− Scrum, Extreme Programming (XP), Test-driven
Development (TDD)
Grupo de Gestão do Conhecimento Coding Dojo e Test-driven Development – 3 / 26
5. Quem sou eu?
• CEFET/RJ
− 9o período, Engenharia de Controle e Automação
• Chemtech
− 11 meses, Projeto Planta Piloto de Biorreator
• Interesses
− Software Livre, ÆÍ»Ä ÒÙÜ, ÈÝØ ÓÒ
− Scrum, Extreme Programming (XP), Test-driven
Development (TDD)
Grupo de Gestão do Conhecimento Coding Dojo e Test-driven Development – 3 / 26
6. Coding Dojo
(baseado nos slides de Danilo Sato e Rodolfo Carvalho)
Grupo de Gestão do Conhecimento Coding Dojo e Test-driven Development – 4 / 26
7. Motivação
Programadores não
treinam!
Grupo de Gestão do Conhecimento Coding Dojo e Test-driven Development – 5 / 26
8. Motivação
Programadores não
treinam!
Por que?
Grupo de Gestão do Conhecimento Coding Dojo e Test-driven Development – 5 / 26
9. Origens
• Kata → Coding Dojo
• Definição: ( ØØÔ »»
Ó Ò Ó ÓºÓÖ )
Reunião na qual um grupo de pessoas se junta para trabalhar
em um desafio de programação. Eles estão lá para se divertir e,
engajados no uso de boas práticas, melhorar suas habilidades.
Grupo de Gestão do Conhecimento Coding Dojo e Test-driven Development – 6 / 26
10. Princípios
• Aprendizado contínuo
• Ambiente seguro
− Não-competitivo
− Colaborativo
− Inclusivo
• Falha e redundância
• Passos de bebê
Grupo de Gestão do Conhecimento Coding Dojo e Test-driven Development – 7 / 26
11. Princípios
• Aprendizado contínuo
• Ambiente seguro
− Não-competitivo
− Colaborativo
− Inclusivo
• Falha e redundância
• Passos de bebê
Grupo de Gestão do Conhecimento Coding Dojo e Test-driven Development – 7 / 26
12. Princípios
• Aprendizado contínuo
• Ambiente seguro
− Não-competitivo
− Colaborativo
− Inclusivo
• Falha e redundância
• Passos de bebê
Grupo de Gestão do Conhecimento Coding Dojo e Test-driven Development – 7 / 26
13. Princípios
• Aprendizado contínuo
• Ambiente seguro
− Não-competitivo
− Colaborativo
− Inclusivo
• Falha e redundância
• Passos de bebê
Grupo de Gestão do Conhecimento Coding Dojo e Test-driven Development – 7 / 26
14. Regras gerais
Grupo de Gestão do Conhecimento Coding Dojo e Test-driven Development – 8 / 26
15. Regras gerais
• Computador + Projetor
Grupo de Gestão do Conhecimento Coding Dojo e Test-driven Development – 8 / 26
16. Regras gerais
• Computador + Projetor
• Par + Platéia
Grupo de Gestão do Conhecimento Coding Dojo e Test-driven Development – 8 / 26
17. Regras gerais
• Computador + Projetor
• Par + Platéia
• TDD (vermelho → verde → refatoração)
Grupo de Gestão do Conhecimento Coding Dojo e Test-driven Development – 8 / 26
18. Regras gerais
• Computador + Projetor
• Par + Platéia
• TDD (vermelho → verde → refatoração)
• Todos devem entender
Grupo de Gestão do Conhecimento Coding Dojo e Test-driven Development – 8 / 26
19. Regras gerais
• Computador + Projetor
• Par + Platéia
• TDD (vermelho → verde → refatoração)
• Todos devem entender
• Sempre começa do zero
Grupo de Gestão do Conhecimento Coding Dojo e Test-driven Development – 8 / 26
20. O formato Randori
• Programação em pares
Grupo de Gestão do Conhecimento Coding Dojo e Test-driven Development – 9 / 26
21. O formato Randori
• Programação em pares
• Turnos time-boxed (5 a 7 minutos)
Grupo de Gestão do Conhecimento Coding Dojo e Test-driven Development – 9 / 26
22. O formato Randori
• Programação em pares
• Turnos time-boxed (5 a 7 minutos)
• Rodízio: após cada turno. . .
− O co-piloto vira piloto
− O piloto volta pra platéia
− Um novo co-piloto é convidado da platéia
Grupo de Gestão do Conhecimento Coding Dojo e Test-driven Development – 9 / 26
23. O formato Randori
• Programação em pares
• Turnos time-boxed (5 a 7 minutos)
• Rodízio: após cada turno. . .
− O co-piloto vira piloto
− O piloto volta pra platéia
− Um novo co-piloto é convidado da platéia
• Comentários e críticas somente no verde
Grupo de Gestão do Conhecimento Coding Dojo e Test-driven Development – 9 / 26
24. O formato Randori
• Programação em pares
• Turnos time-boxed (5 a 7 minutos)
• Rodízio: após cada turno. . .
− O co-piloto vira piloto
− O piloto volta pra platéia
− Um novo co-piloto é convidado da platéia
• Comentários e críticas somente no verde
• Silêncio no vermelho
Grupo de Gestão do Conhecimento Coding Dojo e Test-driven Development – 9 / 26
25. Retrospectiva
• Ao final de cada sessão
− O que aprendemos?
− O que gostamos?
− O que pode melhorar?
− Comentários
Grupo de Gestão do Conhecimento Coding Dojo e Test-driven Development – 10 / 26
26. Objetivo
• Praticar
• Ensinar
• Aprender
• Discutir com bases sobre codigo!
Grupo de Gestão do Conhecimento Coding Dojo e Test-driven Development – 11 / 26
27. O que não faremos
• Correr para terminar o problema
• Resolver problemas “reais”
• Entrar em flame wars nas discussões
• Competir com os outros participantes
• Deixar pessoas sem entender
Grupo de Gestão do Conhecimento Coding Dojo e Test-driven Development – 12 / 26
28. O que não faremos
• Correr para terminar o problema
• Resolver problemas “reais”
• Entrar em flame wars nas discussões
• Competir com os outros participantes
• Deixar pessoas sem entender
Grupo de Gestão do Conhecimento Coding Dojo e Test-driven Development – 12 / 26
29. O que não faremos
• Correr para terminar o problema
• Resolver problemas “reais”
• Entrar em flame wars nas discussões
• Competir com os outros participantes
• Deixar pessoas sem entender
Grupo de Gestão do Conhecimento Coding Dojo e Test-driven Development – 12 / 26
30. O que não faremos
• Correr para terminar o problema
• Resolver problemas “reais”
• Entrar em flame wars nas discussões
• Competir com os outros participantes
• Deixar pessoas sem entender
Grupo de Gestão do Conhecimento Coding Dojo e Test-driven Development – 12 / 26
31. O que não faremos
• Correr para terminar o problema
• Resolver problemas “reais”
• Entrar em flame wars nas discussões
• Competir com os outros participantes
• Deixar pessoas sem entender
Grupo de Gestão do Conhecimento Coding Dojo e Test-driven Development – 12 / 26
32. Podemos. . .
• Experimentar novas idéias
• Nos divertir
• Começar!
− Coding Dojo Chemtech
Segunda-feira, 21 de setembro de 2009 – 17:30-19:00
Grupo de Gestão do Conhecimento Coding Dojo e Test-driven Development – 13 / 26
33. Podemos. . .
• Experimentar novas idéias
• Nos divertir
• Começar!
− Coding Dojo Chemtech
Segunda-feira, 21 de setembro de 2009 – 17:30-19:00
Grupo de Gestão do Conhecimento Coding Dojo e Test-driven Development – 13 / 26
34. Podemos. . .
• Experimentar novas idéias
• Nos divertir
• Começar!
− Coding Dojo Chemtech
Segunda-feira, 21 de setembro de 2009 – 17:30-19:00
Grupo de Gestão do Conhecimento Coding Dojo e Test-driven Development – 13 / 26
35. Test-driven Development
(TDD)
Grupo de Gestão do Conhecimento Coding Dojo e Test-driven Development – 14 / 26
36. Testes unitários e o framework ÜÍÒ Ø
• Método de verificação e validação do funcionamento de
pequenas porções de código
• : framework que visa facilitar a criação,
ÜÍÒ Ø
agrupamento e execução de testes unitários
− ×× ÖØ ÕÙ Ð×´ Ð Ú ÕÙ Ö Ó´¿µ¸ µ
− ×× ÖØÌÖÙ ´ÒÙÑ ÖÓ Ô Ö´ µµ
− ×× ÖØ ÕÙ Ð×´ ÒÚ ÖØ ´³Ø ÜØÓ³µ¸ ³ÓØÜ Ø³µ
− etc.
Grupo de Gestão do Conhecimento Coding Dojo e Test-driven Development – 15 / 26
37. Testes unitários e o framework ÜÍÒ Ø
• Método de verificação e validação do funcionamento de
pequenas porções de código
• : framework que visa facilitar a criação,
ÜÍÒ Ø
agrupamento e execução de testes unitários
− ×× ÖØ ÕÙ Ð×´ Ð Ú ÕÙ Ö Ó´¿µ¸ µ
− ×× ÖØÌÖÙ ´ÒÙÑ ÖÓ Ô Ö´ µµ
− ×× ÖØ ÕÙ Ð×´ ÒÚ ÖØ ´³Ø ÜØÓ³µ¸ ³ÓØÜ Ø³µ
− etc.
Grupo de Gestão do Conhecimento Coding Dojo e Test-driven Development – 15 / 26
38. Testes unitários e o framework ÜÍÒ Ø
• Método de verificação e validação do funcionamento de
pequenas porções de código
• : framework que visa facilitar a criação,
ÜÍÒ Ø
agrupamento e execução de testes unitários
− ×× ÖØ ÕÙ Ð×´ Ð Ú ÕÙ Ö Ó´¿µ¸ µ
− ×× ÖØÌÖÙ ´ÒÙÑ ÖÓ Ô Ö´ µµ
− ×× ÖØ ÕÙ Ð×´ ÒÚ ÖØ ´³Ø ÜØÓ³µ¸ ³ÓØÜ Ø³µ
− etc.
Grupo de Gestão do Conhecimento Coding Dojo e Test-driven Development – 15 / 26
39. O que é TDD?
• Técnica de desenvolvimento que estimula o uso
constante de testes unitários e refatoração
• Quebra de paradigmas!
− O teste é escrito antes do código
− Escrever mais não é desperdício de tempo, é um
investimento
− A implementação não é tão importante
Grupo de Gestão do Conhecimento Coding Dojo e Test-driven Development – 16 / 26
40. O que é TDD?
• Técnica de desenvolvimento que estimula o uso
constante de testes unitários e refatoração
• Quebra de paradigmas!
− O teste é escrito antes do código
− Escrever mais não é desperdício de tempo, é um
investimento
− A implementação não é tão importante
Grupo de Gestão do Conhecimento Coding Dojo e Test-driven Development – 16 / 26
41. O que é TDD?
• Técnica de desenvolvimento que estimula o uso
constante de testes unitários e refatoração
• Quebra de paradigmas!
− O teste é escrito antes do código
− Escrever mais não é desperdício de tempo, é um
investimento
− A implementação não é tão importante
Grupo de Gestão do Conhecimento Coding Dojo e Test-driven Development – 16 / 26
42. O que é TDD?
• Técnica de desenvolvimento que estimula o uso
constante de testes unitários e refatoração
• Quebra de paradigmas!
− O teste é escrito antes do código
− Escrever mais não é desperdício de tempo, é um
investimento
− A implementação não é tão importante
Grupo de Gestão do Conhecimento Coding Dojo e Test-driven Development – 16 / 26
43. Por que desenvolver guiado por testes?
• Feedback instantâneo sobre falhas de software
− Falhas descobertas tarde custam muito caro!
• Ajuda a desenvolver menos, de forma mais simples e
focada
• Os testes servem como documentação atualizada do
funcionamento do código
• Aumenta a confiança do desenvolvedor na hora de
refatorar, e evita o problema do “cobertor curto”
• Atividades mais criativas e menos repetitivas
Grupo de Gestão do Conhecimento Coding Dojo e Test-driven Development – 17 / 26
44. Por que desenvolver guiado por testes?
• Feedback instantâneo sobre falhas de software
− Falhas descobertas tarde custam muito caro!
• Ajuda a desenvolver menos, de forma mais simples e
focada
• Os testes servem como documentação atualizada do
funcionamento do código
• Aumenta a confiança do desenvolvedor na hora de
refatorar, e evita o problema do “cobertor curto”
• Atividades mais criativas e menos repetitivas
Grupo de Gestão do Conhecimento Coding Dojo e Test-driven Development – 17 / 26
45. Por que desenvolver guiado por testes?
• Feedback instantâneo sobre falhas de software
− Falhas descobertas tarde custam muito caro!
• Ajuda a desenvolver menos, de forma mais simples e
focada
• Os testes servem como documentação atualizada do
funcionamento do código
• Aumenta a confiança do desenvolvedor na hora de
refatorar, e evita o problema do “cobertor curto”
• Atividades mais criativas e menos repetitivas
Grupo de Gestão do Conhecimento Coding Dojo e Test-driven Development – 17 / 26
46. Por que desenvolver guiado por testes?
• Feedback instantâneo sobre falhas de software
− Falhas descobertas tarde custam muito caro!
• Ajuda a desenvolver menos, de forma mais simples e
focada
• Os testes servem como documentação atualizada do
funcionamento do código
• Aumenta a confiança do desenvolvedor na hora de
refatorar, e evita o problema do “cobertor curto”
• Atividades mais criativas e menos repetitivas
Grupo de Gestão do Conhecimento Coding Dojo e Test-driven Development – 17 / 26
47. Por que desenvolver guiado por testes?
• Feedback instantâneo sobre falhas de software
− Falhas descobertas tarde custam muito caro!
• Ajuda a desenvolver menos, de forma mais simples e
focada
• Os testes servem como documentação atualizada do
funcionamento do código
• Aumenta a confiança do desenvolvedor na hora de
refatorar, e evita o problema do “cobertor curto”
• Atividades mais criativas e menos repetitivas
Grupo de Gestão do Conhecimento Coding Dojo e Test-driven Development – 17 / 26
48. O ciclo do desenvolvimento guiado por testes
Repita
(Re)Escreva
um teste Teste
passou
Veja se ele
falhou
Teste
falhou Escreva Um ou
código mais testes
falharam
Rode todos
os testes
Todos os
testes
passaram Refatore
Grupo de Gestão do Conhecimento Coding Dojo e Test-driven Development – 18 / 26
49. TDD na sua linguagem
• Â Ú → ÍÒ Ø
• ºÆ Ì → ÒÍÒ Ø
• ÈÝØ ÓÒ → ÙÒ ØØ ×Ø
• ÊÙ Ý → Ì ×Ø ÍÒ Ø
• ÈÀÈ → Ë ÑÔÐ Ì ×Ø
• Â Ú ×
Ö ÔØ → ×ÍÒ Ø
− ÉÙ ÖÝ → ÉÍÒ Ø
• etc.
Grupo de Gestão do Conhecimento Coding Dojo e Test-driven Development – 19 / 26
50. TDD na prática!
Grupo de Gestão do Conhecimento Coding Dojo e Test-driven Development – 20 / 26
51. ÈÝØ ÓÒ
• Sintaxe elegante, simples e clara
• Multiparadigma (OO, procedural, funcional)
• Interpretável
• Tipagem dinâmica, porém forte
• Estruturas de dados de alto nível
− tuplas, listas e dicionários
• Blocos de código são delimitados por endentação
Grupo de Gestão do Conhecimento Coding Dojo e Test-driven Development – 21 / 26
52. ÈÝØ ÓÒ
• Sintaxe elegante, simples e clara
• Multiparadigma (OO, procedural, funcional)
• Interpretável
• Tipagem dinâmica, porém forte
• Estruturas de dados de alto nível
− tuplas, listas e dicionários
• Blocos de código são delimitados por endentação
Grupo de Gestão do Conhecimento Coding Dojo e Test-driven Development – 21 / 26
53. ÈÝØ ÓÒ
• Sintaxe elegante, simples e clara
• Multiparadigma (OO, procedural, funcional)
• Interpretável
• Tipagem dinâmica, porém forte
• Estruturas de dados de alto nível
− tuplas, listas e dicionários
• Blocos de código são delimitados por endentação
Grupo de Gestão do Conhecimento Coding Dojo e Test-driven Development – 21 / 26
54. ÈÝØ ÓÒ
• Sintaxe elegante, simples e clara
• Multiparadigma (OO, procedural, funcional)
• Interpretável
• Tipagem dinâmica, porém forte
• Estruturas de dados de alto nível
− tuplas, listas e dicionários
• Blocos de código são delimitados por endentação
Grupo de Gestão do Conhecimento Coding Dojo e Test-driven Development – 21 / 26
55. ÈÝØ ÓÒ
• Sintaxe elegante, simples e clara
• Multiparadigma (OO, procedural, funcional)
• Interpretável
• Tipagem dinâmica, porém forte
• Estruturas de dados de alto nível
− tuplas, listas e dicionários
• Blocos de código são delimitados por endentação
Grupo de Gestão do Conhecimento Coding Dojo e Test-driven Development – 21 / 26
56. ÈÝØ ÓÒ
• Sintaxe elegante, simples e clara
• Multiparadigma (OO, procedural, funcional)
• Interpretável
• Tipagem dinâmica, porém forte
• Estruturas de dados de alto nível
− tuplas, listas e dicionários
• Blocos de código são delimitados por endentação
Grupo de Gestão do Conhecimento Coding Dojo e Test-driven Development – 21 / 26
57. O problema
• Obter a lista de números primos até um determinado
valor (ex.: 10 → 2, 3, 5, 7)
• Crivo de Eratóstenes
− Gerar lista → 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10
− Remover 0 e 1 → 2, 3, 4, 5, 6, 7, 8, 9, 10
− Para cada numero, remover seus múltiplos da lista,
com exceção dele mesmo
∗ 2 → 2, 3, 5, 7, 9
∗ 3 → 2, 3, 5, 7
∗ ...
Grupo de Gestão do Conhecimento Coding Dojo e Test-driven Development – 22 / 26
58. O problema
• Obter a lista de números primos até um determinado
valor (ex.: 10 → 2, 3, 5, 7)
• Crivo de Eratóstenes
− Gerar lista → 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10
− Remover 0 e 1 → 2, 3, 4, 5, 6, 7, 8, 9, 10
− Para cada numero, remover seus múltiplos da lista,
com exceção dele mesmo
∗ 2 → 2, 3, 5, 7, 9
∗ 3 → 2, 3, 5, 7
∗ ...
Grupo de Gestão do Conhecimento Coding Dojo e Test-driven Development – 22 / 26
59. O problema
• Obter a lista de números primos até um determinado
valor (ex.: 10 → 2, 3, 5, 7)
• Crivo de Eratóstenes
− Gerar lista → 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10
− Remover 0 e 1 → 2, 3, 4, 5, 6, 7, 8, 9, 10
− Para cada numero, remover seus múltiplos da lista,
com exceção dele mesmo
∗ 2 → 2, 3, 5, 7, 9
∗ 3 → 2, 3, 5, 7
∗ ...
Grupo de Gestão do Conhecimento Coding Dojo e Test-driven Development – 22 / 26
60. O problema
• Obter a lista de números primos até um determinado
valor (ex.: 10 → 2, 3, 5, 7)
• Crivo de Eratóstenes
− Gerar lista → 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10
− Remover 0 e 1 → 2, 3, 4, 5, 6, 7, 8, 9, 10
− Para cada numero, remover seus múltiplos da lista,
com exceção dele mesmo
∗ 2 → 2, 3, 5, 7, 9
∗ 3 → 2, 3, 5, 7
∗ ...
Grupo de Gestão do Conhecimento Coding Dojo e Test-driven Development – 22 / 26
61. O problema
• Obter a lista de números primos até um determinado
valor (ex.: 10 → 2, 3, 5, 7)
• Crivo de Eratóstenes
− Gerar lista → 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10
− Remover 0 e 1 → 2, 3, 4, 5, 6, 7, 8, 9, 10
− Para cada numero, remover seus múltiplos da lista,
com exceção dele mesmo
∗ 2 → 2, 3, 5, 7, 9
∗ 3 → 2, 3, 5, 7
∗ ...
Grupo de Gestão do Conhecimento Coding Dojo e Test-driven Development – 22 / 26
63. E agora?
• Seres humanos não gostam de mudanças
− Mudanças devem ser gradativas
• Coding Dojo: experimentação sem cobranças!
Grupo de Gestão do Conhecimento Coding Dojo e Test-driven Development – 24 / 26
64. E agora?
• Seres humanos não gostam de mudanças
− Mudanças devem ser gradativas
• Coding Dojo: experimentação sem cobranças!
Grupo de Gestão do Conhecimento Coding Dojo e Test-driven Development – 24 / 26
65. E agora?
• Seres humanos não gostam de mudanças
− Mudanças devem ser gradativas
• Coding Dojo: experimentação sem cobranças!
Você só sabe o que há
atrás de uma porta depois
que a atravessa!
Grupo de Gestão do Conhecimento Coding Dojo e Test-driven Development – 24 / 26
66. Referências
• ØØÔ »»
Ó Ò Ó ÓºÓÖ »
• ØØÔ »» Ó ÓÖ ÓºÓÖ », ØØÔ »» Ó Ó×ÔºÓÖ »
• Test-Driven Development: By Example – Kent Beck
• ØØÔ »» ÑÔÖÓÚ Øº
ÓѺ Ö»ÜÔ»ÔÖ Ø
×»Ø
• ØØÔ »» ÙÒ Øº×ÓÙÖ
ÓÖ ºÒ Ø» Ó
» Õ» Õº ØÑ
Grupo de Gestão do Conhecimento Coding Dojo e Test-driven Development – 25 / 26