$30 off During Our Annual Pro Sale. View Details »

Pirâmide de testes, escrevendo testes com qualidade @ RubyConf 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

Plataformatec

September 18, 2015
Tweet

More Decks by Plataformatec

Other Decks in Technology

Transcript

  1. Pirâmide de testes
    escrevendo testes com qualidade

    View Slide

  2. Coisas que eu não sabia que eu
    não sabia sobre testes
    escrevendo testes com qualidade

    View Slide

  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

    View Slide

  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?

    View Slide

  5. View Slide

  6. Nossos projetos open source

    View Slide

  7. Nossos livros

    View Slide

  8. Índice
    ● Por que fazer testes (revisão rápida)
    ● Qualidade de testes
    ● Mocks e stubs
    ● Cucumber e especificação por exemplos

    View Slide

  9. Por que fazer testes

    View Slide

  10. Por que fazer testes?
    ● Manter custos de desenvolvimento em níveis saudáveis
    ● Garantir qualidade externa
    ● Ajudar na qualidade interna

    View Slide

  11. Qualidade de testes

    View Slide

  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?"

    View Slide

  13. Qualidade de testes
    Corretude

    View Slide

  14. Corretude
    teste incorreto teste correto

    View Slide

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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

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

    View Slide

  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

    View Slide

  26. Qualidade de testes
    Clareza

    View Slide

  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

    View Slide

  28. 4 fases do xUnit

    View Slide

  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

    View Slide

  30. Na prática: clareza X DRY

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  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?

    View Slide

  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

    View Slide

  36. Escreva exemplos de uso do seu
    código, não testes
    dica para escrever teste claros

    View Slide

  37. Mocks e Stubs

    View Slide

  38. Test doubles
    Mocks e stubs

    View Slide

  39. SUT e collaborator (DOC)
    SUT: system under test
    DOC: depended-on-component (collaborator)
    setup
    exercise
    verify
    teardown
    SUT DOC
    Teste rodando

    View Slide

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

    View Slide

  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

    View Slide

  42. Por que precisamos de mocks?
    Mocks e stubs

    View Slide

  43. Origem de mocks

    View Slide

  44. Uso de mocks segundo seu propósito

    View Slide

  45. Criadores do conceito de mocks

    View Slide

  46. Especificando o Deep Thought

    View Slide

  47. Especificando o Deep Thought

    View Slide

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

    View Slide

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

    View Slide

  50. Interface discovery
    Especificando a API de uma dependência
    deep
    thought
    printer
    print(42)

    View Slide

  51. Especificando o Deep Thought

    View Slide

  52. Especificando o Deep Thought
    test
    double

    View Slide

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

    View Slide

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

    View Slide

  55. Especificando o Deep Thought
    setup
    verify
    exercise
    As fases do xUnit quando usamos mock

    View Slide

  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

    View Slide

  57. Tipos de verificação de teste
    verify
    verify
    verificação por comportamento verificação por estado

    View Slide

  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

    View Slide

  59. Stubs
    Mocks e stubs

    View Slide

  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

    View Slide

  61. Exemplo de stubs
    stubando
    objeto
    client

    View Slide

  62. Exemplo de stubs
    stub: fase
    de setup

    View Slide

  63. Mocks VS Stubs
    Mocks e stubs

    View Slide

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

    View Slide

  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

    View Slide

  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

    View Slide

  67. Cucumber e Especificação por Exemplos

    View Slide

  68. Specification by examples

    View Slide

  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

    View Slide

  70. Cucumber
    especificação + testes = especificação executável

    View Slide

  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

    View Slide

  72. Especificação agile: user stories
    Captura do requisito em formato de user story

    View Slide

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

    View Slide

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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

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

    View Slide

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

    View Slide

  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

    View Slide

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

    View Slide

  82. docs
    docs
    automação

    View Slide

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

    View Slide

  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

    View Slide

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

    View Slide

  86. Concluindo...

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  91. Cupom: HUGO_BARAUNA20
    URL: http://bit.ly/livrohugo
    Cupom de 20% de desconto no meu livro

    View Slide

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

    View Slide

  93. Obrigado! :)
    Hugo Baraúna
    [email protected]
    @hugobarauna

    View Slide