Escolher países para dados de teste costuma acontecer por acidente: alguém abre o formulário, escolhe o país onde mora, gera um exemplo e segue adiante. O resultado é um conjunto pequeno, homogêneo e silenciosamente otimista, que só falha quando aparece um caso real que ninguém previu. Neste texto, tratamos essa escolha como uma decisão de engenharia, com critérios explícitos e um conjunto que pode ser revisado como qualquer outro artefato do projeto.
Por que vale a pena escolher os países com critério?
Porque um conjunto escolhido ao acaso mede muito pouco. Se todos os países da sua amostra usam o alfabeto latino, têm sistema de código postal e cabem em três linhas de endereço, você não está testando um sistema internacional: está testando um sistema nacional com sotaque estrangeiro. A suíte passa, e a confiança que ela produz é falsa.
Existe um segundo motivo, menos óbvio. Um conjunto de países é um pedaço de dados que envelhece. Quando alguém troca um país da lista para investigar uma falha, o significado de todas as asserções daquele dia muda. Sem critério escrito, ninguém consegue dizer se o resultado de ontem e o de hoje são comparáveis.
O terceiro motivo é de custo. Cada país adicional exige exemplos, verificações e documentação. Um conjunto escolhido por critério tende a ser menor do que o conjunto escolhido por entusiasmo, e ainda assim encontra mais defeitos, porque cada elemento dele existe para provar alguma coisa.
Três eixos: alcance, dificuldade e valor de fronteira
O primeiro eixo é o alcance do negócio. Ele pergunta onde a operação realmente acontece: em quais mercados há entrega, cobrança e atendimento. Estados, províncias e regiões desses países entram no teste porque o produto vai precisar deles de verdade.
O segundo eixo é a dificuldade dos dados. Ele olha para a forma do conteúdo, não para o mercado: alfabetos diferentes, escrita da direita para a esquerda, endereços longos, nomes de cidades compridos, campos que às vezes vêm preenchidos e às vezes não. Esse eixo é o que expõe problemas de largura de coluna, truncamento e ordenação.
O terceiro eixo é o valor de fronteira. Ele procura os extremos: o endereço mais longo, o nome de país mais comprido, o país que não tem determinado campo. Fronteira não é curiosidade; é o lugar onde as regras de tamanho e obrigatoriedade são postas à prova.
| Eixo | Pergunta que ele responde | O que ele costuma revelar |
|---|---|---|
| Alcance | Onde o produto opera de fato | Campos que faltam em mercados já atendidos |
| Dificuldade | Como o conteúdo se parece | Truncamento, ordenação, largura fixa |
| Fronteira | Onde a regra quebra | Limites de tamanho e campos inaplicáveis |
Os três eixos não competem entre si. Um país pode servir a dois deles ao mesmo tempo, e isso é bom: conjuntos menores com mais propósito são mais fáceis de manter do que listas longas e redundantes.
O que faz de um país um bom caso de fronteira
Um bom caso de fronteira tem pelo menos uma característica que força o sistema a sair do caminho confortável. Ele pode ter o nome mais longo do conjunto, ou um endereço que ocupa mais linhas do que o layout reserva, ou um alfabeto que não cabe na largura de uma etiqueta.
Também vale como fronteira o país cuja estrutura é mais simples do que o formulário espera. Quando o modelo de dados presume uma hierarquia que aquele lugar não usa, o teste de fronteira deixa de ser sobre formato e passa a ser sobre o próprio modelo, que é onde os defeitos caros moram.
O detalhe que separa um bom caso de fronteira de uma escolha pitoresca é a consequência. Se o país entra no conjunto e nada muda no comportamento do sistema quando ele é removido, ele não é fronteira: é decoração.
Países sem código postal ou sem divisão interna: como testar?
Esse é o caso que mais aparece em projetos que começam pelo formulário. O instinto é marcar tudo como obrigatório, porque o banco tem a coluna, e a coluna não aceita vazio. Só que a obrigatoriedade não é uma propriedade do sistema: é uma propriedade da combinação entre sistema e país.
O caminho que funciona é separar três estados desde o começo. O campo pode estar preenchido; pode não existir naquele contexto, o que é diferente de estar vazio; e pode estar simplesmente ausente, quando deveria ter valor. Uma asserção de campo obrigatório só faz sentido no terceiro estado.
Consequência prática: a suíte precisa conter pelo menos um país em que o campo não se aplica. Sem esse elemento, a verificação de obrigatoriedade vai reprovar dado legítimo, e alguém vai “consertar” o teste afrouxando a regra para todos os países. O estrago é maior do que o defeito original.
Como montar um conjunto padrão
Um conjunto que costuma funcionar na prática tem três camadas, com papéis distintos e complementares.
- Um ou dois países de casa, onde a equipe conhece o domínio de cor e reconhece qualquer resultado estranho à primeira vista.
- Dois ou três mercados principais, escolhidos pelo alcance real do negócio, que exercitam as regras de entrega e de cobrança.
- Alguns valores de fronteira, escolhidos pelo formato e pela ausência de campo, e não pela familiaridade.
Vale manter o conjunto pequeno o suficiente para caber numa revisão de trinta minutos. Um conjunto que ninguém revisa não é um conjunto de teste; é uma tabela esquecida.
Para quem desenvolve: tratar o conjunto de países como ativo versionado
A recomendação central deste texto é simples: dê um número de versão ao conjunto de países, do mesmo jeito que se versiona uma migração de banco. Quando a lista muda, a versão muda, e o resultado de cada execução fica amarrado à versão usada.
Na prática, isso significa guardar a lista como dado, e não espalhada pelo código em condições e exceções. Um arquivo de definição revisável, com o motivo de cada país, permite que a próxima pessoa entenda por que aquele elemento está ali antes de removê-lo.
Vale também registrar, para cada país, quais campos se aplicam. A pergunta “este campo vale aqui?” precisa ter resposta consultável, não resposta deduzida de memória. Quando essa informação está no conjunto, a asserção de obrigatoriedade passa a ser condicional e correta, em vez de universal e errada.
Por fim, nunca preencha um conjunto de teste com dados de pessoas ou empresas reais. Um conjunto de teste existe para ser copiado, impresso e colado em relatórios; dado real em qualquer uma dessas etapas vira incidente.
Próximos passos
Depois de definir o conjunto, o passo natural é medir o que ele cobre. A lista de cobertura de dados por país mostra como registrar, campo a campo, o que está preenchido, o que não se aplica e o que está faltando. Se a sua dúvida já é sobre manutenção, o texto sobre atualidade dos dados de país trata de fontes e datas de coleta. E a página de formatos de endereço e identidade por país serve para comparar a sua lista com a organização do site antes de fechar a sua.
Aviso sobre os exemplos: os países, regiões e valores citados neste texto são um conjunto sintético, criado apenas para ilustrar critérios de escolha. Ele não descreve nenhuma base real, não representa a lista de mercados de nenhuma empresa e não deve ser usado como fonte para cadastro, faturamento ou qualquer decisão operacional.