Coding Dojo e Test Driven Development

1.451 visualizações

Publicada em

Publicada em: Tecnologia
0 comentários
1 gostou
Estatísticas
Notas
  • Seja o primeiro a comentar

Sem downloads
Visualizações
Visualizações totais
1.451
No SlideShare
0
A partir de incorporações
0
Número de incorporações
47
Ações
Compartilhamentos
0
Downloads
7
Comentários
0
Gostaram
1
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Coding Dojo e Test Driven Development

  1. 1. VII EncontroCoding Dojo e Test Driven Development
  2. 2. Brunno Gomes  twitter.com/brunnogomes brunnolgp@gmail.com
  3. 3. Rodrigo Alves Vieira rodrigo3n.com  twitter.com/rodrigo3n  rodrigo3n@gmail.com
  4. 4. Coding Dojo +  Test DrivenDevelopment
  5. 5. Coding Dojo?
  6. 6. flickr{rosie_hardy}
  7. 7. Test DrivenDevelopment  
  8. 8. flickr{chuckbiscuito}
  9. 9. Técnica apresentada por Kent Beck em seu livro (Test  Driven Development: By  Example, 2003), tem como  objetivo aumentar a  qualidade do software  escrito além das  capacidades do  programador 
  10. 10. Hmmm, TDD?!.. 
  11. 11. ...Python tem o...
  12. 12. unittest
  13. 13. unittest
  14. 14. flickr{shutterhack} unittest
  15. 15. • O unittest (também chamado de  PyUnit) é um Framework built-in do  Python para Testes Unitários criado  por Steve Purcell em 2001. Baseado  no JUnit e no Smalltalk Testing  Framework• Está incluso na biblioteca padrão do  Python desde a versão 2.1 (2001).
  16. 16. Vantagens• É uma biblioteca padrão do Python
  17. 17. Vantagens• É uma biblioteca padrão do Python• É muito prática. Curva mínima de aprendizado
  18. 18. Vantagens• É uma biblioteca padrão do Python• É muito prática. Curva mínima de aprendizado• Presente em todos os interpretadores do Python
  19. 19. Vantagens• É uma biblioteca padrão do Python• É muito prática. Curva mínima de aprendizado• Presente em todos os interpretadores do Python• É util pra qualquer projeto!
  20. 20. Qualquerprojeto!
  21. 21. O Framework•TestCase
  22. 22. O Framework•TestCase•TestSuite
  23. 23. O Framework•TestCase•TestSuite•TextTestRunner
  24. 24. Comece testando o código que você quer ter!
  25. 25. unittest.TestCase# -*- encoding:utf-8 -*-# aviao_teste.pyimport unittestfrom aviao import Aviaoclass AviaoTeste(unittest.TestCase): """ Documentação de AviaoTest """ def testeAviaoCriado(self): aviao = Aviao(10) self.assertNotEqual(aviao == None, aviao)if __name__ == "__main__": unittest.main()
  26. 26. flickr{saguar} Obviamente falha!
  27. 27. Completamos o primeiro passo do ciclo do TDD: escrevemos um teste como queremos que o código funcione.  Agora escreveremos apenas o código suficiente para fazer o teste passar!
  28. 28. # -*- encoding:utf-8 -*-# aviao.pytanque = 10class Aviao(): def __init__(self, encher_o_tanque=tanque): print "Executando testes..."
  29. 29. flickr{naty_nina}Fizemos o primeiro teste passar! Agora vem a...
  30. 30. flickr{finsterbaby} ...Refatoração!
  31. 31. Aqui pensamos atenciosamente no que os  testes estão fazendo. Melhoramos a qualidade do  código fonte e do próprio  teste e removemos  duplicação
  32. 32. # -*- encoding:utf-8 -*-# aviao_teste.pyimport unittestfrom aviao import Aviaoclass AviaoTeste(unittest.TestCase): """ Documentação de AviaoTest """ def testeAviaoCriado(self): aviao = Aviao(10) self.assertNotEqual(aviao == None, aviao), "Avião não pode ser None"if __name__ == "__main__": unittest.main()
  33. 33. Pro-dica: Execute os testes com a opção -v e veja  a execução de cada teste em modo verboso!~λ python aviao_teste.py -v
  34. 34. unittest.TestSuite Uma ferramenta do unittest para  agrupar testes individuais e organizar pilhas de testes, mesmo  em diferentes arquivos/módulos,  criando Suítes de Teste!
  35. 35. Criando uma suíte de Testes # -*- encoding:utf-8 -*- # aviao_test_suite.py import unittest import aviao_teste def suite(): testsuite = unittest.TestSuite() testsuite.addTest(unittest.makeSuite(AviaoTeste) return testsuiteOu ainda melhor...
  36. 36. A classe TestSuite torna ainda mais poderosa sua suíte de testes porque você  pode importar quantos módulos quiser  contendo uma quantidade qualquer de  testes! Então você pode aninhar os testes para  dinamizar a execução!
  37. 37. E com aninhar eu quis dizer que você  pode aninhar até outras suítes de testes!import unittestfrom aviao_test_suite import AviaoTestSuitefrom outro_modulo import OutraTestSuitesuite1 = aviao_test_suite.AviaoTestSuitesuite2 = outro_modulo.OutraTestSuiteteste_geral = unittest.TestSuite((suite1, suite2))Uma suíte de testes que execua outra suíte de testes! Massa!
  38. 38. unittest.TextTestRunner Claro que testes são documentação também, então, nada melhor que  tê-los disponíveis em  texto puro! 
  39. 39. E é exatamente isso que o TextTestRunner  faz cada vez que o invocamos com "unittest.main()" no arquivo aviao_teste.py!unittest.main() gera um objeto TestSuite que  contém todos os testes(métodos) que  começam com "test" (testAviaoCriado,  por exemplo) , então ele invoca o  TextTestRunner que executa cada um dos  testes e te retorna o resultado via stderr!
  40. 40. Nossa suíte final de testes!# -*- encoding:utf-8 -*-# aviao_teste_suite.pyimport unittestfrom aviao_test import *class AviaoTesteSuite(unittest.TestSuite): def __init__(self): unittest.TestSuite.__init__(self.map(AviaoTeste, ("AviaoTeste"))) def suite(self): suite = unittest.TestSuite() suite.addTest(unittest.makeSuite(AviaoTeste)) return suitesuite1 = unittest.TestSuite()suite1.addTest(AviaoTeste("testeAviaoCriado"))unittest.TextTestRunner().run(suite1)unittest.TextTestRunner(verbosity=2).run(suite())
  41. 41. mais informações: help(unittest)
  42. 42. flickr{ibcbulk}Fazer TDD écomo andar debicicleta!
  43. 43. Coding Dojo
  44. 44. Porque ?
  45. 45. Nós nãotreinamos.
  46. 46. O que é ?
  47. 47. De acordo com o CodingDojo.Org “Um encontro onde um grupo deprogramadores se junta para trabalhar num desafio de programação. O objetivo é sedivertir praticar deliberadamente de forma a melhorar suas habilidades.”
  48. 48. PráticaDeliberada.
  49. 49. Não é...
  50. 50. ...um lugar para pura exibição.
  51. 51. ... competição.
  52. 52. Características
  53. 53. • Passos de bebê• Todos são iguais• Todos devem entender• Sempre começa do zero
  54. 54. • Sempre se usa testes• Iterativo e Interativo• Interrupções incentivadas• Abertura para novas idéias
  55. 55. Algumas regras
  56. 56. • Computador + Projetor• Piloto + co-piloto• TDD vermelho → verde → refatorar
  57. 57. Estilos
  58. 58. PreparedKata
  59. 59. • Piloto e co-piloto fixos• Apresentam uma solução do início ao fim• Cada passo é explicado
  60. 60. • Indicado para um grande número de participantes• Pode-se usar um problema e solução previamente preparados
  61. 61. RandoriKata
  62. 62. • Piloto e co-piloto revezam• Todos os presentes são convidados a participar• Cada par tem um tempo para programar
  63. 63. • Indicado para grupos menores• O ideal é que todos os participantes programem
  64. 64. Problemas e Soluções
  65. 65. • Problemas simples• Qualquer um pode propor• Tem que começar e terminar na mesma sessão do Dojo
  66. 66. Depois do Dojo
  67. 67. • O que aprendemos ?• O que foi bom ?• O que foi ruim ?
  68. 68. Valeu! o/

×