Pro Yearly is on sale from $80 to $50! »

Pirâmide de testes, escrevendo testes com qualidade @ RubyConf 2015

7c12adb8b5521c060ab4630360a4fa27?s=47 Plataformatec
September 18, 2015

Pirâmide de testes, escrevendo testes com qualidade @ RubyConf 2015

- parâmetros para avaliar a qualidade de um teste e de uma suite de testes
- pirâmide de testes
- mocks não são apenas para testes, são para design
- cucumber não é uma ferramenta de testes, mas sim de documentação
- testing iceberg

7c12adb8b5521c060ab4630360a4fa27?s=128

Plataformatec

September 18, 2015
Tweet

Transcript

  1. Pirâmide de testes escrevendo testes com qualidade

  2. Coisas que eu não sabia que eu não sabia sobre

    testes escrevendo testes com qualidade
  3. • Testes de view não são ruins • Mock não

    é apenas uma ferramenta de teste • Mockar => Stubar • Cucumber não é uma ferramenta de teste Quebrar alguns dogmas e pré-conceitos
  4. Hugo Baraúna - Co-fundador e sócio da Plataformatec - Engenheiro

    de computação pela Poli-USP - Autor do livro "Cucumber e RSpec" pela Casa do Código Quem sou eu?
  5. None
  6. Nossos projetos open source

  7. Nossos livros

  8. Índice • Por que fazer testes (revisão rápida) • Qualidade

    de testes • Mocks e stubs • Cucumber e especificação por exemplos
  9. Por que fazer testes

  10. Por que fazer testes? • Manter custos de desenvolvimento em

    níveis saudáveis • Garantir qualidade externa • Ajudar na qualidade interna
  11. Qualidade de testes

  12. Qualidade de testes Como posso avaliar se meu teste ou

    suíte está com qualidade? • Corretude ◦ "o teste está verificando o comportamento correto do código?" • Adequação do tipo de teste ◦ "o teste foi feito com o tipo mais adequado?" • Clareza ◦ "está fácil de entender sobre o que é o teste?"
  13. Qualidade de testes Corretude

  14. Corretude teste incorreto teste correto

  15. Qualidade de testes Adequação do tipo de teste

  16. • Aceitação ◦ testa um requisito funcional, normalmente pela UI

    • Unitário ◦ testa o comportamento de 1 objeto • Integração ◦ teste entre aceitação e unitário, testando comportamento de 2 ou mais objetos juntos Tipos de teste Para cada comportamento a ser testado, deve ser avaliado o tipo de teste mais adequado
  17. Na prática: testes de aceitação São sobre o domínio do

    problema (regras de negócio), não sobre o domínio de UI ou de Web
  18. Na prática: testes de aceitação São sobre o domínio do

    problema (regras de negócio), não sobre o domínio de UI ou de Web domínio do problema domínio de web dev domínio de web UI domínio de web dev
  19. Na prática: testes de aceitação São sobre o domínio do

    problema (regras de negócio), não sobre o domínio de UI ou de Web
  20. Na prática: testes de aceitação São sobre o domínio do

    problema (regras de negócio), não sobre o domínio de UI ou de Web domínio do problema domínio do problema domínio do problema
  21. • Aceitação: testa um requisito funcional, normalmente pela UI •

    Unitário: testa o comportamento de 1 objeto • Integração: teste entre aceitação e unitário, testando comportamento de 2 ou mais objetos juntos Adequação do tipo de teste Para cada comportamento a ser testado, deve ser avaliado o tipo de teste mais adequado
  22. Quantos testes fazer em cada camada? Pirâmide de testes: guia

    para estratégia de testes, baseado na natureza do tipo de teste aceitação integração unitário
  23. Quantos testes fazer em cada camada? Pirâmide de testes: guia

    para estratégia de testes, baseado na natureza do tipo de teste aceitação integração unitário (+) frágil (+) lento (+) garantia qualidade externa (-) frágil (+) rápido (-) garantia qualidade externa
  24. Na prática: escolher um tipo de teste apropriado A aba

    padrão desta tela é a aba "Comprador". Qual tipo de teste usar?
  25. Na prática: escolher um tipo de teste apropriado - Devemos

    fazer poucos testes de acceptance, e vários de unidade - Podemos usar teste unitário de view, pois teste de acceptance não é para especificação de tela e sim para spec de regras do domínio do negócio
  26. Qualidade de testes Clareza

  27. 4 fases do xUnit Um teste pode ser estruturado segundo

    as 4 fases padrão do xUnit: 1. Setup: coloca o sistema no estado necessário 2. Exercise: interage com o objeto sob teste 3. Verify: verifica o comportamento esperado 4. Teardown: coloca o sistema no estado antes do teste
  28. 4 fases do xUnit

  29. Clareza = Causa e consequência Um teste é claro quando

    é fácil de entender a relação de causa e consequência entre as fases do xUnit dado o seguinte estado do meu sistema quando exercito tal ação nele então consigo verificar tal comportamento esperado setup exercise verify
  30. Na prática: clareza X DRY

  31. Na prática: clareza X DRY repetição

  32. Na prática: clareza X DRY O teste está claro? DRY!

  33. Na prática: clareza X DRY O teste está claro?

  34. Na prática: avaliar a clareza de um teste O teste

    está claro? - em que estado o objeto game precisa estar para ser setado como 100? - o que tem ser feito no objeto game para que ele sete o score para 100?
  35. • Uso excessivo de DRY nos testes prejudica a clareza

    • DRY não deve ser aplicado em código de teste do mesmo modo que em código de produção • Favoreça clareza sobre DRY Na prática: clareza X DRY
  36. Escreva exemplos de uso do seu código, não testes dica

    para escrever teste claros
  37. Mocks e Stubs

  38. Test doubles Mocks e stubs

  39. SUT e collaborator (DOC) SUT: system under test DOC: depended-on-component

    (collaborator) setup exercise verify teardown SUT DOC Teste rodando
  40. DOC Test double Test double: um objeto que substitui o

    DOC real setup exercise verify teardown SUT Test double Teste rodando
  41. Tipos de test doubles Existem vários tipos de test doubles,

    cada um com um propósito e uso específico. • stub • mock • spy • fake • dummy object Mais detalhes em http://xunitpatterns.com/Test%20Double.html
  42. Por que precisamos de mocks? Mocks e stubs

  43. Origem de mocks

  44. Uso de mocks segundo seu propósito

  45. Criadores do conceito de mocks

  46. Especificando o Deep Thought

  47. Especificando o Deep Thought

  48. Especificando o Deep Thought STDOUT.read # => IOError: not opened

    for reading
  49. Interface discovery Especificando a API de uma dependência deep thought

  50. Interface discovery Especificando a API de uma dependência deep thought

    printer print(42)
  51. Especificando o Deep Thought

  52. Especificando o Deep Thought test double

  53. Especificando o Deep Thought test double injeção de dependência

  54. Especificando o Deep Thought test double injeção de dependência mockei

    o test double
  55. Especificando o Deep Thought setup verify exercise As fases do

    xUnit quando usamos mock
  56. Verificação: estado X comportamento objeto objeto objeto objeto objeto objeto

    tradicional: verificação pelo estado final do objeto com mocks: verificação pelo interação entre os objetos
  57. Tipos de verificação de teste verify verify verificação por comportamento

    verificação por estado
  58. O que é um mock? • Mock é um test

    double usado na fase de verify • Mockar um objeto é programá-lo para verificar se ele recebeu as mensagens corretas do SUT • Criado originalmente para ser usado com a técnica de interface discovery
  59. Stubs Mocks e stubs

  60. O que é um stub? • Stub é um test

    double usado na fase de setup • Stubar um objeto é programá-lo para retornar uma resposta para um certo método
  61. Exemplo de stubs stubando objeto client

  62. Exemplo de stubs stub: fase de setup

  63. Mocks VS Stubs Mocks e stubs

  64. Diferença entre mocks e stubs Mocks são para verify e

    stubs são para setup verify setup mocks stubs
  65. Na prática: usar a terminologia corretamente • Ao fazer um

    teste de aceitação que tem como detalhe consumir dados de uma API, qual é o correto? ◦ mockar API ◦ stubar API
  66. Na prática: usar a terminologia corretamente • Ao fazer um

    teste de aceitação que tem como detalhe consumir dados de uma API, qual é o correto? ◦ mockar API ◦ stubar API
  67. Cucumber e Especificação por Exemplos

  68. Specification by examples

  69. A falta de opinião do Cucumber Cucumber não é uma

    ferramenta de testes, é uma ferramenta de especificação e documentação testes de UI Cucumber
  70. Cucumber especificação + testes = especificação executável

  71. Living documentation Especificação tradicional X Especificação executável Documentação tradicional fica

    desatualizada com o passar do tempo Documentação executável se mantém atualizada com o passar do tempo
  72. Especificação agile: user stories Captura do requisito em formato de

    user story
  73. Especificação por exemplos Especificar utilizando exemplos dos critérios de aceite

  74. Especificação executável Automatizar a especificação com testes automatizados especificação automação

    da especificação
  75. Processo de especificação por exemplos Escopo (user stories) Especificação (ilustrar

    com exemplos) Automatizar com testes (especificação executável) Documentação viva
  76. Quando usar Cucumber • Quando o domínio do negócio for

    complexo ◦ o domínio do negócio tem muitos termos que não são de conhecimento público • Para algum comportamento do sistema que for muito complexo e houver valor em documentá-lo com linguagem natural ◦ difícil de entender o propósito do código apenas através da leitura código • Quando houver pessoas que precisam saber o comportamento do sistema mas que não consigam ler o código-fonte ◦ suporte, analistas de negócio e outros stakeholders • Para documentar um overview do comportamento do sistema ◦ exemplo da documentação do RSpec e VCR
  77. Como usar Cucumber • use a linguagem do domínio do

    problema, não a de interface com usuário • escreva documentação, não apenas automação de testes • não precisa usar para todos os testes end-to-end, só para os que envolvem a necessidade de documentação
  78. Como usar Cucumber Use a linguagem do domínio do problema,

    não a de interface com usuário
  79. Como usar Cucumber Use a linguagem do domínio do problema,

    não a de interface com usuário
  80. Como usar Cucumber Use a linguagem do domínio do problema,

    não a de interface com usuário linguagem de web UI linguagem do domínio do problema
  81. Como usar o Cucumber Escreva documentação, não apenas automação de

    testes automação
  82. docs docs automação

  83. Como usar o Cucumber Escreva documentação, não apenas automação de

    testes apenas automação documentação + automação
  84. Testing iceberg Nem todos os business-readable tests precisam ser end-to-end

    business facing acceptance tests End-to-end integration tests business facing end-to-end acceptance tests
  85. Testing iceberg aceitação (end-to-end) integração unitário Business readable Technical (non-business

    readable)
  86. Concluindo...

  87. Qualidade de testes • Prefira clareza ao invés de DRY

    nos testes • Organize sua suite segundo a pirâmide de testes • Substitua "testes de aceitacão" por testes de view ou testes unitários de Javascript • Testes de aceitação são sobre regras de negócio, não sobre especificação da UI Concluindo
  88. Mocks e stubs • Stubs são para fase de setup,

    mocks são para a de verify • Quando alguém fala "mockar", provavelmente ele/ela quer dizer "stubar" • Mocks foram feitos com o propósito de fazer design com a técnica de interface discovery Concluindo
  89. Concluindo Cucumber • Cucumber é uma ferramenta de documentação, não

    de testes (especificação por exemplos) • Você não precisa usar Cucumber para todos os testes end-to-end da sua aplicação • É possível fazer business-readable tests sem ser end-to-end
  90. Outros materiais para estudar • http://guidelines.plataformatec.com.br/rspec.html • Vídeo da Plataformatec

    sobre pirâmide de testes: http://bit.ly/em-foco-testes • Paper para entender origem de mocks: Mock roles, not Objects • Livro sobre BDD com Cucumber e RSpec, do Hugo Baraúna • Livro sobre testes avançado: Growing object-oriented software guided by tests • Livro sobre a metodologia por trás do Cucumber: Specification by Example
  91. Cupom: HUGO_BARAUNA20 URL: http://bit.ly/livrohugo Cupom de 20% de desconto no

    meu livro
  92. Estamos contratando http://plataformatec.com.br/careers

  93. Obrigado! :) Hugo Baraúna hugo.barauna@plataformatec.com.br @hugobarauna