Your SlideShare is downloading. ×
Mantendo a Qualidade dos Códigos de Teste
Mantendo a Qualidade dos Códigos de Teste
Mantendo a Qualidade dos Códigos de Teste
Mantendo a Qualidade dos Códigos de Teste
Mantendo a Qualidade dos Códigos de Teste
Mantendo a Qualidade dos Códigos de Teste
Mantendo a Qualidade dos Códigos de Teste
Mantendo a Qualidade dos Códigos de Teste
Mantendo a Qualidade dos Códigos de Teste
Mantendo a Qualidade dos Códigos de Teste
Mantendo a Qualidade dos Códigos de Teste
Mantendo a Qualidade dos Códigos de Teste
Mantendo a Qualidade dos Códigos de Teste
Mantendo a Qualidade dos Códigos de Teste
Mantendo a Qualidade dos Códigos de Teste
Mantendo a Qualidade dos Códigos de Teste
Mantendo a Qualidade dos Códigos de Teste
Mantendo a Qualidade dos Códigos de Teste
Mantendo a Qualidade dos Códigos de Teste
Mantendo a Qualidade dos Códigos de Teste
Mantendo a Qualidade dos Códigos de Teste
Mantendo a Qualidade dos Códigos de Teste
Mantendo a Qualidade dos Códigos de Teste
Mantendo a Qualidade dos Códigos de Teste
Mantendo a Qualidade dos Códigos de Teste
Mantendo a Qualidade dos Códigos de Teste
Mantendo a Qualidade dos Códigos de Teste
Mantendo a Qualidade dos Códigos de Teste
Mantendo a Qualidade dos Códigos de Teste
Mantendo a Qualidade dos Códigos de Teste
Mantendo a Qualidade dos Códigos de Teste
Mantendo a Qualidade dos Códigos de Teste
Mantendo a Qualidade dos Códigos de Teste
Mantendo a Qualidade dos Códigos de Teste
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Mantendo a Qualidade dos Códigos de Teste

1,028

Published on

Apresentação feita no Agile Brazil 2011, em Fortaleza, por Maurício Eduardo Szabo …

Apresentação feita no Agile Brazil 2011, em Fortaleza, por Maurício Eduardo Szabo

Recomendo baixar a apresentação, a versão do slideshare não apresenta algumas animações que são essenciais para o entendimento

Published in: Technology
1 Comment
0 Likes
Statistics
Notes
  • Be the first to like this

No Downloads
Views
Total Views
1,028
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
15
Comments
1
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. AgileBrazil 2011 Melhorando a Qualidade dos Códigos de Teste Maurício Eduardo Szabo [email_address] @mauricio_szabo http://mauricioszabo.wordpress.com http://github.com/mauricioszabo/AgileBrazil2011
  • 2. about:me
    • Programador Ruby, Java, Python, Scala, C/C++, etc...
    • 3. Scrum Master
    • 4. Test-Addicted
    • 5. Clean-Code Addicted
    • 6. Enfim...
  • 7. Intro
    • Agilidade, mudanças contínuas, requisitos mutantes
      • Garantia de estabilidade – testes
      • 8. ”Dedo duro” - sempre saber o estado de seu sistema
      • 9. Confiabilidade no código, acabar com o ”medo de mudar”
      • 10. Requisitos mudam == testes mudam
  • 11. Intro – Testes se Pagam
    • Testes demoram para ser escritos?
  • 12. Mudança - Exemplo
    • Parsing de HTML
      • Quero uma lista de todos os homens na página
      • 13. Para saber se o Ariovaldo está aparecendo na listagem de homens
  • 14. Minha Abordagem: BDD
    • Testes x Comportamento
      • Deixa eu ver se isso funciona...
        • assert(this, works());
      • Deixa eu ver se está fazendo isso mesmo...
        • assertThat(this, isDoing(right));
    • Assert x Should
      • (Assert x Matcher)
    • Big Picture – Small Picture – Smaller Picture – Unit Test
  • 15. Primeiros Exemplos
    • Situação: elemento está verde?
  • 16. Mudança de ”Estilo”
    • Situação: salário válido deve calcular IRPF
  • 17. (Evitar Cometer) Erros Comuns
  • 18. JAMAIS!!!
  • 19. Oops... Certos testes não dizem NADA Certos testes dizem DEMAIS
  • 20. Framework de Testes O que usar, como usar, por que usar?
  • 21. Framework de Testes
    • Test/Unit, JBehave, RSpec, ScalaTest, JUnit, Jasminne, JSpec...
    • 22. Mocks: Mocha, FlexMock, Mockito, JMock, etc...
    • 23. Escolha corretamente: Um framework de testes:
      • Deve ser extensível
      • 24. Deve ser flexível
    • Um framework de mocks:
      • Deve refletir a forma como você pensa
  • 25. Framework de Testes
  • 26. Codebase
    • Comparação entre código e linhas de teste 1:1 (se possível)
    • 27. Testes devem crescer junto com seu código
      • Classes auxiliares, métodos, custom matchers, etc
    • Conforme seu projeto vai crescendo, a dificuldade de escrever novos testes deve ficar constante ou diminuir!
  • 28. Mocks
    • Expectations: antes do teste, o define-se o que esperamos que o mock receba
      • (Mocha, RSpec, FlexMock, JMock)
    • Assertions: depois do teste, vemos o que o mock recebeu
      • (Mockito)
  • 29. Eu uso...
    • Para Ruby: RSpec, e às vezes, Mocha
    • 30. Para Scala: ScalaTest com Mockito
    • 31. Para Java: JUnit (com os Hamcrest matchers) e Mockito
    • 32. Para JavaScript: Jasminne
  • 33. Primeiro, resolva o problema
    • Represente! A vida é um teatro!
    • 34. Não escreva NADA antes de resolver o problema
    • 35. Protótipos são válidos, mas devem ser descartados
  • 36. Então, escreva o código
    • Teste vem PRIMEIRO
    • 37. Código vem DEPOIS
    • 38. Somente um teste deve falhar por vez
      • Quer dizer...
  • 39. Somente um teste falhando?
    • Mini-integrações
  • 40. Ambiente Isolado
    • Todo teste, no BDD, é um cenário
    • 41. Pensar num teatro:
      • Montar o cenário (Setup)
      • 42. Apresentação (para o código)
      • 43. Aceitação do público
      • 44. Desmontar tudo
    • Peça foi um fracasso: ainda assim, desmontar tudo
      • TearDown
    Infra-Estrutura do Teatro Setup Apresentação Aceitação
  • 45. Preparação não pode ficar implícita
    • (Muito comum no RSpec / Ruby)
  • 46. Mas também, nada de explícita
    • (Comum com situações que exigem muito ”setup”)
  • 47. Meio-Termo
    • Métodos que ajudam a construir o cenário ideal
  • 48. Métricas (LOC)
    • Setup (montar o cenário):
      • Ideal: de 1 a 4 linhas
      • 49. Ruim: de 5 a 7 linhas
      • 50. Maior que 7: Rever a preparação do Cenário
    • Chamada de método:
      • Ideal: 1 linha
      • 51. Péssimo: maior que 2 linhas
    • JAMAIS:
      • Use IF, CASE, ou qualquer condicional!
  • 52. Estilo de Teste Como fazer seu teste ter menos cara de código e mais cara de texto.
  • 53. Bee English
    • Dê sentido para as coisas!
  • 54. Bee English
    • Falta de Sentido: ”que é que isso fazia mesmo???”
  • 55. Bee English
    • Pense em como você descreveria aquele pedaço
    • 56. Adapte o texto até chegar à linguagem de teste
  • 57. Bee English
    • Monte sua ”história” baseando-se na linguagem
  • 58. Uma Última Coisa Mocks e Stubs
  • 59. Stub!
    • Stub como forma de ”controle”
    • 60. Programação Funcional
    Stub em algum lugar aqui dentro...
  • 61. Devil's Advocate
    • Mas... e com a correria?
      • Mas... você não demora mais pra fazer isso?
    • Mas... a empresa (coloque aqui sua empresa favorita) não usa isso...
    • 62. Mas... meu código sequer tem testes, como eu vou aplicar isso?
  • 63. That's It
    • Perguntas?
    • 64. Idéias?
    • 65. Contato:
      • [email_address]
      • 66. @mauricio_szabo
      • 67. http://mauricioszabo.wordpress.com
      • 68. http://github.com/mauricioszabo/AgileBrazil2011

×