Nos últimos anos, uma coisa ficou óbvia para mim: escrever testes de API não é a parte difícil.
Mantê-los úteis é.
Em diferentes projetos, continuei vendo os mesmos três problemas aparecerem repetidamente. Nenhum deles foi causado por ferramentas ruins ou desenvolvedores ruins. Eles foram simplesmente o resultado de APIs evoluindo mais rápido do que os testes ao seu redor.
Aqui estão as três mudanças que fizeram a maior diferença para nós.
1. Pare de tratar sua especificação de API como documentação
Durante muito tempo mantivemos três versões diferentes da mesma API:
- Documentação OpenAPI
- Casos de teste
- Respostas simuladas
Eventualmente eles se separaram.
Alguém atualizaria a API, mas esqueceria de atualizar os testes.
Ou a documentação.
Ou as zombarias.
Em vez disso, começamos a tratar a especificação OpenAPI como a fonte da verdade.
A API muda uma vez.
Todo o resto segue.
Mesmo que você não gere testes automaticamente, ter um contrato canônico reduz drasticamente a manutenção.
2. Separe os testes de contrato dos testes de negócios
Um erro que cometemos no início foi colocar todas as afirmações no mesmo teste.
Por exemplo:
Create Customer
↓
Status = 201
↓
Schema Valid
↓
Business Rules
↓
Database Validation
Quando o teste falhou, encontrar a causa real demorou.
Em vez disso, agora dividimos responsabilidades.
Testes de contrato
- Códigos de status
- Cabeçalhos
- Campos obrigatórios
- Esquema de resposta
Testes de negócios
- Preços
- Permissões
- Regras de validação
- Fluxos de trabalho
Os testes tornaram-se muito mais fáceis de entender e de manter.
3. Não zombe de tudo
Por um tempo, zombamos de todas as dependências externas.
O conjunto de testes foi rápido.
Também era excesso de confiança.
Eventualmente descobrimos que diversas falhas de produção foram causadas por suposições que nossas simulações nunca exerceram.
Hoje usamos três camadas.
- **Testes unitários – **Mock tudo.
- **Testes de integração – **Simulação apenas de sistemas que não controlamos.
- **Validação de pré-lançamento – **Execute um pequeno pacote em serviços reais ou ambientes sandbox oficiais.
É mais lento, mas detecta problemas que simulações perfeitas nunca conseguirão.
Uma lição que eu não esperava
Os testes de autenticação agora consomem mais tempo de CI do que qualquer outra coisa.
Fluxos OAuth, atualização de token, contas de serviço, segredos rotativos… todos são necessários, mas também são caros para serem testados adequadamente.
Estou curioso para saber como outras equipes estão lidando com isso hoje.
Você é:
- Testando em um provedor de identidade real?
- Executando uma simulação local?
- Usando tokens pré-gerados?
- Fazendo algo completamente diferente?
Também gostaria de saber como você está abordando a paginação baseada em cursor e testando APIs de terceiros, por exemplo, Stripe ou Twilio, etc.
Cada equipe parece ter uma resposta diferente e suspeito que não exista uma única “melhor” solução.
