Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Pirâmide de testes, escrevendo testes com quali...

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

Plataformatec

September 18, 2015
Tweet

More Decks by Plataformatec

Other Decks in Technology

Transcript

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

    testes escrevendo testes com qualidade
  2. • 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
  3. 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?
  4. Índice • Por que fazer testes (revisão rápida) • Qualidade

    de testes • Mocks e stubs • Cucumber e especificação por exemplos
  5. Por que fazer testes? • Manter custos de desenvolvimento em

    níveis saudáveis • Garantir qualidade externa • Ajudar na qualidade interna
  6. 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?"
  7. • 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
  8. 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
  9. 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
  10. 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
  11. 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
  12. • 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
  13. 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
  14. 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
  15. Na prática: escolher um tipo de teste apropriado A aba

    padrão desta tela é a aba "Comprador". Qual tipo de teste usar?
  16. 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
  17. 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
  18. 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
  19. 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?
  20. • 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
  21. SUT e collaborator (DOC) SUT: system under test DOC: depended-on-component

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

    DOC real setup exercise verify teardown SUT Test double Teste rodando
  23. 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
  24. 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
  25. 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
  26. 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
  27. Diferença entre mocks e stubs Mocks são para verify e

    stubs são para setup verify setup mocks stubs
  28. 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
  29. 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
  30. 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
  31. 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
  32. Processo de especificação por exemplos Escopo (user stories) Especificação (ilustrar

    com exemplos) Automatizar com testes (especificação executável) Documentação viva
  33. 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
  34. 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
  35. 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
  36. Como usar o Cucumber Escreva documentação, não apenas automação de

    testes apenas automação documentação + automação
  37. 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
  38. 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
  39. 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
  40. 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
  41. 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