Guia em 7 passos: fixtures sintéticas de QA sem dado real

Este guia em 7 passos explica como montar fixtures sintéticas de QA para uma plataforma multi-tenant sem jamais tocar dado real. Toda plataforma desse tipo chega a um ponto em que precisa provar que o sistema de permissões separa quem pode escrever de quem só pode ler. Precisa provar também que uma conta sem nenhuma organização não alcança dado nenhum.

Provar isso contra uma conta de cliente real é inaceitável. Um teste de autorização que falha do jeito errado pode vazar conteúdo de outra empresa. Um teste de limite de taxa pode queimar a reputação de envio de e-mail transacional de toda a base. A resposta da casa para esse problema são as fixtures sintéticas de QA, um conjunto pequeno e descartável de contas, organizações, sites e conteúdo. Esse conjunto nasce pelo mesmo caminho que um cliente real usaria, mas sob um domínio de e-mail que nunca entrega a uma pessoa de verdade.

1. Fixtures sintéticas de QA: por que o domínio de teste é a peça central#

O requisito não negociável é simples de enunciar. O endereço de e-mail da fixture tem de estar sob um TLD reservado pela RFC 2606, como .test, .invalid ou .example. Vale também um subdomínio próprio da casa com MX nulo, conforme a RFC 7505.

Nos dois casos, o resultado prático é o mesmo. Não existe servidor de e-mail do outro lado, então qualquer tentativa de entrega morre na resolução de DNS antes de sair da rede. Nenhuma caixa de entrada real recebe nada. Nenhum provedor de envio vê um bounce, e a reputação do domínio de produção nunca é tocada por um teste automatizado que roda de madrugada.

2. O desvio para o sink, não para a caixa#

Mesmo com o domínio corretamente reservado, o sistema ainda precisa saber o código de verificação que enviaria por e-mail. Sem isso a fixture nunca sai do estado pendente. A solução não é desligar a verificação para contas de teste, pois isso abriria uma porta de bypass permanente. Também não é confiar numa caixa de e-mail real de teste, pois isso reintroduz o risco que o domínio reservado deveria eliminar.

O caminho certo é um desvio dentro do próprio serviço de autenticação. Antes de qualquer chamada ao provedor de envio, o servidor reconhece o domínio sintético e grava o código num registro estruturado local, sem nunca o enviar de fato. Quem opera o sistema lê esse registro por um canal de leitura já existente, como o journal do serviço, e nunca por uma caixa de e-mail.

3. O ciclo de vida completo de uma conta sintética#

Toda rodada de fixtures sintéticas de QA sob um domínio de teste reservado começa pela conta. Uma fixture completa não é só uma linha na tabela de usuários. Ela percorre o mesmo fluxo que um cliente novo percorreria: cadastro público com senha, confirmação de e-mail por código e primeiro login com o segundo fator disponível.

Quando o teste pede, a conta também passa pelo cadastro de um aplicativo autenticador (TOTP), atrás de uma reautenticação recente. Pular qualquer uma dessas etapas, por exemplo inserindo a linha direto no banco, testaria um caminho que nenhum cliente real jamais percorre. Um bug introduzido numa dessas etapas passaria batido justamente onde mais importa.

4. Organização, site e papéis — a topologia mínima#

No desenho de fixtures sintéticas de QA, depois da conta vem a topologia: pelo menos duas organizações, cada uma com um site próprio, e pelo menos três papéis diferentes testáveis ao mesmo tempo — proprietário, editor e leitor. Essa combinação é o que permite provar, numa única rodada, que um editor não consegue promover um colega a proprietário, que um leitor não consegue publicar nada e que ninguém de uma organização alcança o site da outra. Uma conta sem organização nenhuma completa o quadro: ela prova que o sistema nega por padrão (deny-by-default) quando não há vínculo nenhum, em vez de simplesmente não testar esse caminho.

5. Chaves de API com escopos deliberadamente diferentes#

Boa parte das fixtures sintéticas de QA também cobre tráfego automatizado. Além das contas humanas, a maior parte do tráfego real contra uma API de conteúdo vem de integrações automatizadas — robôs de publicação, painéis de parceiros, ferramentas de redação. Por isso a fixture também emite pelo menos duas chaves por site: uma com escopo de escrita e leitura (posts:write, posts:read), outra só de leitura. A chave de leitura existe para um propósito específico: provar que ela recebe 403 ao tentar qualquer escrita, em vez de simplesmente nunca ser testada nesse caminho. Um sistema de permissões só está provado depois que alguém tenta o que não devia conseguir e recebe a recusa certa — não depois que alguém só tenta o que já devia funcionar.

6. Conteúdo de teste: rascunho e publicado, de propósito#

Por fim, cada site recebe pelo menos dois posts, um em rascunho e outro publicado. A diferença entre os dois estados exercita caminhos de código inteiramente distintos. O rascunho nunca aparece na listagem pública nem no feed, nunca é indexado e nunca dispara aviso de publicação.

O post publicado passa pela trava de qualidade da casa, que mede, entre outras coisas e segundo o guia de boas práticas de teste da OWASP sobre superfícies expostas, se o conteúdo tem estrutura mínima antes de ir ao ar. Se aprovado, fica visível imediatamente pela mesma API pública que um leitor de verdade usaria. Testar os dois estados ao mesmo tempo garante que nenhum deles vaza silenciosamente para o outro. Um rascunho que aparece publicado é tão grave quanto um post publicado que some da listagem.

7. Limpeza e idempotência, para a próxima rodada#

Uma fixture que não pode ser apagada de volta não é uma fixture. É um vazamento permanente de dados sintéticos misturados aos reais. O desenho correto grava, para cada recurso criado, o comando exato de remoção e a ordem em que ele precisa rodar: membros antes da organização, site antes da organização dona, chave antes do site.

Sem esse registro, toda rodada nova de teste herda lixo da rodada anterior e os números deixam de significar o que deveriam. Os códigos de resposta HTTP usados em cada chamada seguem a semântica padrão descrita pela documentação de status HTTP do MDN. São eles: 201 para criado, 409 para conflito já existente, 403 para proibido e 429 para limite de taxa. Um teste automatizado que não distingue esses quatro casos não está realmente testando nada.

8. O que o limite de taxa do próprio login ensina#

Um efeito colateral pouco falado de montar fixtures sintéticas de QA pelo caminho público é que esse caminho passa pelos mesmos freios que protegem uma conta real contra força bruta e enumeração. São eles o limite de tentativas de cadastro por IP, o limite de reenvio de código por conta e um disjuntor que trava de vez depois de poucas chamadas repetidas em sequência curta.

Isso não é um obstáculo a contornar. É exatamente o comportamento que o teste deveria confirmar. A disciplina certa é chamar cada etapa uma vez, esperar a resposta completa e só então decidir o próximo passo. Insistir "para depurar" é a forma mais comum de transformar uma suspeita de bug no próprio disjuntor disparando de verdade. Quando o limite aparece, a resposta correta é parar, registrar onde e retomar depois do resfriamento, nunca pedir para a regra geral do ambiente de produção ficar mais permissiva só porque um teste está com pressa.

9. Consistência eventual entre serviços vizinhos#

Outra lição prática vem de uma arquitetura com serviço de identidade e serviço de conteúdo separados. Criar uma organização num serviço e, no instante seguinte, criar um site que depende dela no outro, pode encontrar uma janela curta de inconsistência. A concessão ainda não chegou pelo canal assíncrono que replica o vínculo para a camada de autorização que o segundo serviço consulta.

Isso não é um bug de autorização. É o preço de não acoplar os dois serviços num único banco compartilhado, que é exatamente o desenho que impede que a queda de um derrube o outro. A fixture que encontra esse 403 passageiro tem duas opções sãs. Pode esperar poucos segundos e tentar de novo uma única vez, ou tratar o 403 imediatamente após uma criação como "tente de novo", nunca como "a permissão está errada".

10. Um checklist curto antes de declarar a fixture pronta#

Antes de entregar o conjunto de fixtures sintéticas de QA para a próxima etapa, neste caso uma rodada de pentest ao vivo, vale confirmar sete pontos, nessa ordem. Primeiro, todo endereço de e-mail usado está mesmo sob um domínio reservado ou sob o subdomínio de teste da casa, nunca sob um provedor real. Segundo, cada conta percorreu o cadastro público de verdade, não uma inserção direta no banco. Terceiro, pelo menos duas organizações independentes existem, cada uma com seu próprio site.

Quarto, os três papéis mínimos, proprietário, editor e leitor, estão representados e logáveis. Quinto, existe pelo menos uma chave de API só de leitura, criada de propósito para provar a recusa de escrita. Sexto, cada site tem conteúdo nos dois estados que importam, rascunho e publicado. Sétimo e último, existe um registro completo de como desfazer cada recurso, na ordem certa, para a próxima rodada começar limpa.

Quando os sete itens batem, a fixture está pronta para receber tráfego de teste de verdade, inclusive tentativas deliberadas de furar a regra, que é o próximo passo depois deste artigo. Nenhum desses sete pontos substitui o outro. Uma fixture com domínio reservado mas sem os três papéis cobre menos superfície do que parece. Uma fixture com todos os papéis mas sem o registro de remoção acumula lixo a cada rodada subsequente de teste. É por isso que uma rodada de fixtures sintéticas de QA bem desenhada vale o esforço de montagem: ela se paga em cada rodada de teste seguinte, sem acumular dívida nenhuma para quem vier depois.

Este artigo é, ele mesmo, uma fixture: foi publicado no site de teste pt-qa-site-b.canverly.net, sob a categoria pt-qa, para validar a página de detalhe, o feed e a nota de SEO mínima exigida antes de qualquer publicação real. Veja também o site de teste, a categoria de fixtures e o post em rascunho irmão deste, usado para provar o caminho que nunca deveria ficar visível.