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

Like this? Share it with your network

Share

Mantendo a Qualidade dos Códigos de Teste

  • 1,303 views
Uploaded 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

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to like this
No Downloads

Views

Total Views
1,303
On Slideshare
1,192
From Embeds
111
Number of Embeds
2

Actions

Shares
Downloads
15
Comments
1
Likes
0

Embeds 111

http://www.techgig.com 88
http://10.150.200.57 23

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