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

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