Dados de identidade em dados fixos de teste são o que permite dizer que um defeito foi corrigido de verdade. Quando o conjunto de entrada muda a cada execução, uma falha não pode ser reproduzida e uma correção não pode ser verificada: o teste passa hoje e falha amanhã sem que ninguém tenha mexido no código. Neste texto, mostramos como organizar registros de identidade em conjuntos fixos, quais amostras vale a pena guardar e como impedir que elas apodreçam com o tempo.
O que é um conjunto de dados fixo
Um dado fixo é um registro guardado junto do teste, com um nome, que não muda entre execuções. Ele serve como entrada conhecida e como saída esperada. Em um teste de cadastro, o conjunto fixo define quem está se cadastrando: nome, documento, nascimento, endereço e telefone, todos escolhidos à mão e mantidos no repositório.
A alternativa é gerar valores a cada execução. Isso é útil para descobrir defeitos que dependem de variação, mas péssimo para testar igualdade, porque o valor esperado muda junto com a entrada. Um caso de teste que compara a saída com um valor guardado precisa de um conjunto fixo; um caso que apenas verifica se o sistema aceita a entrada pode usar valores novos.
Por que dado aleatório impede a reprodução de falhas?
Imagine um teste que falha uma vez a cada tanto e passa quando você o executa de novo. Sem saber qual registro foi usado na execução que falhou, não há como investigar: o dado desapareceu junto com o processo. Em muitos sistemas, o registro nem chega a ser registrado em lugar algum, e a única pista que sobra é a linha do relatório dizendo que a asserção falhou.
Registros fixos resolvem isso porque o dado é parte do caso de teste. O relatório pode citar o nome do conjunto, e qualquer pessoa reproduz a falha com a mesma entrada. É a diferença entre um defeito investigável e um defeito que se resolve por sorte.
Há um meio-termo que costuma dar bom resultado: usar geração aleatória para variar, mas fixar a semente. Assim o conjunto é diferente de um teste para outro e idêntico entre execuções do mesmo teste. Muitos geradores de dados de teste trabalham dessa forma, e o gerador de identidade desta página também permite fixar uma chave de identidade para reproduzir exatamente o mesmo registro.
Como nomear e organizar os conjuntos?
A organização é o que separa um conjunto útil de uma pasta de arquivos soltos. Três decisões fazem quase todo o trabalho:
- Um conjunto por cenário, com nome que descreva o cenário. Cadastro de pessoa adulta, cadastro com documento de outro país, cadastro com recusa de idade mínima. O nome precisa dizer para que serve o conjunto, não quem o criou.
- Relação explícita com o caso de teste. Cada conjunto deve ser citado por um ou mais casos, e cada caso deve saber qual conjunto usa. Conjuntos órfãos envelhecem sem que ninguém perceba.
- Campos completos e coerentes. Guarde o registro inteiro, não apenas o campo em teste, porque a maior parte dos defeitos aparece na combinação entre campos.
Quais amostras de borda vale a pena guardar?
Algumas amostras pagam o custo de manutenção porque quebram sistemas de maneiras que ninguém prevê. Estas são as que costumam valer:
| Amostra | Por que ela existe | O que ela quebra |
|---|---|---|
| Pessoa com idade muito avançada | testa limites de data e exibição | contas de idade e formatação de três dígitos |
| Nome muito longo | testa largura de campo e impressão | truncamento silencioso em telas e etiquetas |
| Pessoa sem sobrenome | testa obrigatoriedade indevida | validação que exige o campo |
| Nome com caracteres não latinos | testa codificação de ponta a ponta | conversões e comparações de texto |
| Documento de país diferente | testa a regra por país | validação que assume um único formato |
| Nascido em 29 de fevereiro | testa o cálculo de idade | aniversário nos anos comuns |
Repare que nenhuma dessas amostras precisa de dados de pessoas reais, e nenhuma delas deve ser obtida copiando um cadastro. Os registros são inventados e servem apenas para testes; não podem ser usados para se passar por outra pessoa.
Para quem desenvolve: estrutura e manutenção
A estrutura mais simples que funciona é um registro por cenário, guardado em um formato legível e com os campos nomeados exatamente como o sistema os recebe. Isso evita a tradução entre o nome do campo no arquivo e o nome no código, que é uma fonte constante de erro.
Sobre a manutenção, o risco real é a corrosão. Um conjunto que foi correto ontem pode ficar inválido hoje por três motivos: a regra do produto mudou, o formato do documento do país mudou, ou o próprio sistema passou a exigir um campo novo. Três medidas mantêm isso sob controle:
- Uma verificação automática que valida os conjuntos. Se o conjunto deixa de passar na validação que o sistema aplica, o problema aparece no teste e não em produção.
- Poucos conjuntos por cenário. Cada conjunto é uma obrigação de manutenção. Amostras redundantes quebram juntas e ninguém sabe qual delas ainda importa.
- Um responsável por conjunto. Sem dono, o conjunto fica no repositório até alguém apagá-lo por engano.
Vale ainda separar os conjuntos por tipo de sistema. Um conjunto de identidade usado para testar cadastro não é o mesmo que um conjunto usado para testar relatórios, e misturá-los cria dependências que ninguém pediu. Se o seu caso envolve várias pessoas na mesma cena, mantenha as relações explícitas: quem é titular, quem é dependente, quem compartilha endereço.
Próximos passos
Escolha hoje três cenários do seu sistema e dê a cada um um conjunto fixo com nome, registro completo e relação explícita com o caso de teste. Gere os valores de partida no gerador de identidade e ajuste à mão apenas o que o cenário exigir. Se a dúvida é como o conjunto se comporta em ambiente compartilhado, o texto sobre dados de teste e GDPR trata do que não deve ser copiado para lá.