Navegue neste artigo
A tela abre, o formulário envia e a demonstração funciona. Isso ainda não prova que o sistema protege os dados ou se recupera de uma falha. Vamos revisar uma API de pedidos como exemplo.
Escolha o fluxo que não pode falhar
Comece com uma jornada curta: entrar, consultar um pedido e atualizar seu endereço. Registre quem pode fazer cada ação e qual estado deve existir ao final. Use uma cópia de teste, sem credenciais nem dados reais de clientes.
Antes de refatorar, anote a versão do código e reproduza o comportamento atual. O objetivo é separar falhas observadas de hipóteses e preferências de estilo.
Teste a autorização sem passar pela interface
Esconder um botão não protege uma API. Envie a requisição diretamente com uma sessão sem permissão e depois com uma sessão de outra empresa. O servidor deve verificar identidade, vínculo com a empresa e acesso ao pedido antes de retornar ou alterar qualquer dado.
O identificador da empresa usado para filtrar os dados deve vir de uma identidade validada no servidor. Não confie em um campo enviado pelo navegador para decidir a qual conta a operação pertence.
# Cenários de teste, não comandos de produção
GET /orders/42 sem sessão -> acesso negado
GET /orders/42 com usuário de outra empresa -> sem dados
PATCH /orders/42 sem permissão de escrita -> sem alteração
PATCH /orders/42 com endereço inválido -> validação falhaA política pode responder 403 ou ocultar a existência com 404. O importante é não revelar dados e aplicar o comportamento definido de forma consistente.
Revise o caminho de erro e as dependências
Interrompa a integração externa no ambiente de teste. A aplicação informa uma falha útil? Encerra a tentativa? Cria um registro parcial? Se a mesma requisição chegar de novo, a ação será duplicada? Essas perguntas são mais importantes que trocar o nome de uma variável.
Procure também segredos no código, mensagens de erro com dados pessoais e dependências que ninguém consegue justificar. Um relatório automático é um ponto de partida: confirme se cada achado afeta a versão e o caminho usados pelo produto.
- Timeouts e tentativas limitadas para integrações.
- Validação de entradas e tratamento de retornos inesperados.
- Transações e regras de idempotência nas ações com efeitos externos.
- Logs suficientes para investigar, sem tokens ou dados desnecessários.
Feche a revisão com uma mudança verificável
Escolha um risco relevante, escreva um teste que o reproduza e corrija em uma mudança pequena. Execute os testes da jornada, o build e as verificações estáticas. Registre o que foi comprovado e o que continua fora do escopo.
Antes de publicar, ensaie a migração e o retorno da aplicação em um ambiente compatível. Reverter o código não desfaz automaticamente uma alteração de dados. Defina como detectar uma regressão e quem decide interromper a publicação.
- Entrega do exercício: um teste de acesso entre empresas, a correção e sua evidência.
- Critério de aceite: o usuário autorizado conclui a jornada e o usuário de outra conta não acessa o pedido.
- Próximo passo: revisar um segundo fluxo, sem transformar a revisão em uma reescrita completa.
Fontes e leituras relacionadas
Material educativo. Valide os exemplos em um ambiente de teste e adapte as decisões ao contexto, aos riscos e às responsabilidades do seu projeto.
Compartilhar