1- Por quê?

Por que ter testes automatizados?

1. Para evitar regressão.

Fim

Regressão

Regressão

• Antes funcionava
• Agora não funciona mais

Regressão

• O que quebra não é a funcionalidade nova
• Quebra outra parte que você nem mexeu!
• E nem sempre quebra imediatamente
  • O bug pode ser descoberto N releases depois
    • Vide `git bisect`

Regressão

• Trabalho miserável / "inútil"
  • Consertar o que já estava funcionando
  • Toma tempo precioso da equipe
    • "À toa"
  • E explode na mão do cliente!
• Pode gerar efeito dominó
  • "Bug que criei ao corrigir outro bug"
• Queima o filme da equipe
  • Perante a diretoria
    • (E vai gerando "trauma da entrega")
  • Perante o cliente
    • (E a reputação da empresa vai junto)

Regressão queima o filme da empresa

• Caso: Salesforce/Apex
  • Força você a escrever testes
  • Por que, se o software nem é deles?

Regressão custa caro

E mais caro quanto mais perto de produção.

• Levantamento de requisitos: 100
• QA: 1.500
• Produção: 10.000

 

Departamento de Comércio dos EUA:

"bugs de software custam 59,5 bilhões de dólares para a economia americana"

 

https://www.isixsigma.com/industries/software-it/defect-prevention-reducing-costs-and-enhancing-quality/

https://www.celerity.com/the-true-cost-of-a-software-bug

 

Fonte: IBM System Sciences Institute

Fonte: a experiência do cara, baseado em um wage de USD 100,00/hora.

Por que o custo sobe tanto?

• Envolve mais gente
  • Cliente
  • Suporte N1
  • Suporte N2
  • PM
  • Equipe de desenvolvimento
  • Desenvolvedor
• É um desvio
• Pode gerar outros custos
  • Infraestrutura
  • Negação de serviço
  • Processos legais

Ou seja

• Se ter testes torna o processo 2x mais demorado...
  • Ainda assim se paga!

1- Eliminação do

cagaço-de-mexer

• Típico de integrantes novos
• Tende a atrasar as entregas
  • E "incomodar" os colegas

 

Depois que mexo no código, que garantia eu tenho de que não quebrei nada?

 

"Parece okay" é insuficiente.

2- Código "hermético"

• Outra pessoa pode mexer no "teu" código
  • Se fizer algo errado, os testes detectam!

3- Testes são uma forma de documentação

"Atenção: é muito importante jamais permitir que um usuário do grupo X altere configurações da seção Y!"

• Questões de controle de acesso (segurança)
• Checagem de possíveis abusos
• Casos especiais

4- Falhar local é muito melhor que falhar em produção

• Público afetado = 1 pessoa (você)
• Fora do ciclo de deploy
• Rule of Repair: When you must fail, fail noisily and as soon as possible.

Como começar

1. Bugs
2. Novas funcionalidades
3. Código "em repouso"

Bugs

• Nenhum bug é "corrigido" sem testes para comprovar
• Correção em 2 etapas:
  1. Entender o problema e escrever o teste
     • (que deve falhar)
  2. Fazer o teste passar

(pytest)

Novas funcionalidades

• Se não tem teste comprovando que funciona,
  • então não funciona
  • e, se funcionar por pura sorte, vai bugar em breve.
  • É necessário uma "prova formal".

 

("Nova funcionalidade" nem sempre é "entrega".)

Ferramentas

• Checklist
• Code coverage

Checklist

• Interessante: usar template de Pull Request
  • Incluir: "tem testes?"
• Na definição das tarefas, incluir "escrever os testes"

Code coverage

• É possível impedir que a cobertura decaia.
  • (PR fica "bloqueado")
• Mas primeiro precisa medir!
  • Ou seja: configurar CI adequadamente.
  • No começo, pode ser um git-hook.

Seja rápido!

• Localmente: mais fácil
  • (Se for difícil e lento, você não usa)
• No CI: mais barato
  • (Cada minuto conta)

Faça bom uso de transactions+rollbacks

• Evite I/O no HDD/SDD!
• ("Se usa banco é unitário?" - a discussão é longa...)
• SGBDs geralmente suportam transações aninhadas.

Evite I/O no geral

• I/O na rede local = teste de integração
• I/O no disco = apenas com fixtures

Capriche nas mensagens de erro

• Da aplicação:
  • Deve guiar o usuário
• Dos testes:
  • Deve guiar o desenvolvedor
  • Seguir a ideia de "alertas acionáveis"
  • Os nomes dos testes devem ser descritivos também

Cultura

Pessoas > Processos

• Nenhum processo se estabelece sozinho
• Ter testes dá mais trabalho
  • Exige
    • compromisso
    • boa-vontade
    • disciplina
    • flexibilidade
    • visão de médio/longo-prazo