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

Slide 1

Slide 1 text

Pirâmide de testes escrevendo testes com qualidade

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

● 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

Slide 4

Slide 4 text

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?

Slide 5

Slide 5 text

No content

Slide 6

Slide 6 text

Nossos projetos open source

Slide 7

Slide 7 text

Nossos livros

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

Por que fazer testes

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

Qualidade de testes

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

Qualidade de testes Corretude

Slide 14

Slide 14 text

Corretude teste incorreto teste correto

Slide 15

Slide 15 text

Qualidade de testes Adequação do tipo de teste

Slide 16

Slide 16 text

● 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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

● 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

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

Qualidade de testes Clareza

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

4 fases do xUnit

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

Na prática: clareza X DRY

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

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?

Slide 35

Slide 35 text

● 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

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

Mocks e Stubs

Slide 38

Slide 38 text

Test doubles Mocks e stubs

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

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

Slide 42

Slide 42 text

Por que precisamos de mocks? Mocks e stubs

Slide 43

Slide 43 text

Origem de mocks

Slide 44

Slide 44 text

Uso de mocks segundo seu propósito

Slide 45

Slide 45 text

Criadores do conceito de mocks

Slide 46

Slide 46 text

Especificando o Deep Thought

Slide 47

Slide 47 text

Especificando o Deep Thought

Slide 48

Slide 48 text

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

Slide 49

Slide 49 text

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

Slide 50

Slide 50 text

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

Slide 51

Slide 51 text

Especificando o Deep Thought

Slide 52

Slide 52 text

Especificando o Deep Thought test double

Slide 53

Slide 53 text

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

Slide 54

Slide 54 text

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

Slide 55

Slide 55 text

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

Slide 56

Slide 56 text

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

Slide 57

Slide 57 text

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

Slide 58

Slide 58 text

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

Slide 59

Slide 59 text

Stubs Mocks e stubs

Slide 60

Slide 60 text

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

Slide 61

Slide 61 text

Exemplo de stubs stubando objeto client

Slide 62

Slide 62 text

Exemplo de stubs stub: fase de setup

Slide 63

Slide 63 text

Mocks VS Stubs Mocks e stubs

Slide 64

Slide 64 text

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

Slide 65

Slide 65 text

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

Slide 66

Slide 66 text

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

Slide 67

Slide 67 text

Cucumber e Especificação por Exemplos

Slide 68

Slide 68 text

Specification by examples

Slide 69

Slide 69 text

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

Slide 70

Slide 70 text

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

Slide 71

Slide 71 text

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

Slide 72

Slide 72 text

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

Slide 73

Slide 73 text

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

Slide 74

Slide 74 text

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

Slide 75

Slide 75 text

Processo de especificação por exemplos Escopo (user stories) Especificação (ilustrar com exemplos) Automatizar com testes (especificação executável) Documentação viva

Slide 76

Slide 76 text

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

Slide 77

Slide 77 text

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

Slide 78

Slide 78 text

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

Slide 79

Slide 79 text

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

Slide 80

Slide 80 text

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

Slide 81

Slide 81 text

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

Slide 82

Slide 82 text

docs docs automação

Slide 83

Slide 83 text

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

Slide 84

Slide 84 text

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

Slide 85

Slide 85 text

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

Slide 86

Slide 86 text

Concluindo...

Slide 87

Slide 87 text

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

Slide 88

Slide 88 text

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

Slide 89

Slide 89 text

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

Slide 90

Slide 90 text

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

Slide 91

Slide 91 text

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

Slide 92

Slide 92 text

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

Slide 93

Slide 93 text

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