Menu

Validação de data de nascimento: erros e casos de borda

A validação de data de nascimento erra em lugares previsíveis: 29 de fevereiro, cálculo de idade, fuso horário e calendários não gregorianos. Veja como tratar cada caso.

Publicado em

  • data de nascimento
  • validação
  • casos de borda

A validação de data de nascimento parece um dos problemas mais simples de um cadastro e é uma das fontes mais confiáveis de defeito silencioso. O calendário tem exceções, a idade depende do dia em que é calculada, e o dia de hoje não é o mesmo em todos os lugares ao mesmo tempo. Neste texto, reunimos os casos que mais quebram sistemas, explicamos por que eles passam despercebidos e mostramos como montar dados de teste que realmente exercitam essas situações.

O calendário não é tão regular quanto parece

O primeiro ponto é o ano bissexto. A regra gregoriana é direta: um ano é bissexto quando é divisível por quatro, mas os anos de virada de século só são bissextos quando também são divisíveis por quatrocentos. Isso significa que 1900 não foi bissexto e 2000 foi. Quem implementa a regra pela metade aceita o primeiro e recusa o segundo, ou o contrário, e o defeito só aparece quando alguém digita uma data antiga ou uma data muito próxima do ano 2000.

A consequência prática é o dia 29 de fevereiro. Uma pessoa nascida nesse dia existe legalmente em todos os lugares, mas o sistema precisa decidir como tratar o aniversário nos anos comuns. Alguns países consideram que a pessoa faz aniversário no dia 28 de fevereiro; outros, no dia 1º de março. Um cálculo de idade que faz uma conta simples de anos pode errar o dia exato em qualquer uma das duas convenções.

Há ainda calendários que não são o gregoriano. Etiópia, Nepal e Irã usam calendários próprios, e o mesmo dia do calendário civil aparece escrito de outra forma nesses sistemas. Um formulário que assume o calendário gregoriano vai interpretar mal uma data que a pessoa digitou corretamente no calendário local.

Quando alguém completa anos?

A idade em anos completos é calculada comparando o dia de hoje com o aniversário, e a resposta usual é: quem faz aniversário hoje já tem a nova idade. Isso vale para a contagem de anos, e não para todas as verificações de idade do mundo, porque cada sistema pode definir o critério por conta própria. O que não funciona em nenhum caso é subtrair os anos e ignorar o dia.

Vale lembrar que a idade é uma grandeza derivada. Guardar a idade como número é a origem de defeitos que ninguém entende depois: no dia seguinte, o valor guardado fica errado. A data de nascimento é o dado; a idade é uma conta feita na hora da exibição.

O que acontece com o fuso horário?

Isso importa mais do que a maioria dos times imagina. Se o servidor está configurado em um fuso e o navegador em outro, a mesma data pode ser lida como o dia anterior ou o dia seguinte. O caso clássico é o de uma pessoa que completa a idade mínima hoje e tenta se cadastrar à noite: dependendo do fuso usado na conta, ela tem a nova idade ou ainda não.

A recomendação corrente é armazenar a data de nascimento como data pura, sem hora e sem fuso, e fazer a conta de idade sempre a partir da data de referência que o próprio sistema define. Misturar data pura com um instante de tempo completo é o que cria a diferença de um dia.

Uma data de preenchimento pode virar uma data real?

Pode, e é um dos defeitos mais difíceis de rastrear. Muitos formulários aceitam a data que já vem no campo, seja para agilizar o preenchimento, seja porque o valor é calculado. Em dados de teste, é comum usar valores arredondados como primeiro de janeiro de um ano qualquer, ou datas completamente inválidas como o primeiro de janeiro de um ano distante.

Quando esse valor entra em um relatório, em uma estatística de perfil de usuários ou em uma amostra enviada para outra equipe, ele passa a ser lido como informação. Uma distribuição de idades cheia de valores arredondados é o sinal de que ninguém conferiu a origem dos dados. Em um sistema real, o equivalente é a data de nascimento que a pessoa preencheu por preguiça e nunca corrigiu.

Tabela de casos de borda

Os casos abaixo cobrem a maior parte dos defeitos reais. Cada um exige um registro próprio no conjunto de teste, porque cada um falha de maneira diferente.

Caso Valor de exemplo O que ele verifica
Aniversário hoje mesmo dia e mês da data de referência o critério de idade adotado
Um dia antes véspera do aniversário se o sistema adianta a idade
Nascido em 29 de fevereiro ano bissexto o tratamento do aniversário nos anos comuns
Recém-nascido data de hoje e depois se o campo aceita idade zero
Muito idoso nascimento no início do século passado se o sistema aceita idades de três dígitos
Virada de século 1900 e 2000 a regra de ano bissexto completa
Data futura amanhã se a validação rejeita o impossível
Data em calendário local data escrita em outro calendário se o sistema assume só o gregoriano

Cada linha dessa tabela corresponde a um caso de teste que vale a pena manter. Nas datas, uma diferença de um único dia pode separar um cadastro aceito de um recusado, e é exatamente por isso que a véspera é o valor mais útil de todos.

Para quem desenvolve: decisões que envelhecem bem

Três escolhas resolvem a maior parte dos problemas de data de nascimento:

  • Guarde a data, não a idade. Um campo de idade no banco de dados fica errado no dia seguinte ao cadastro. Calcule a partir da data de nascimento no momento em que precisar.
  • A data é pura, sem hora. Um campo com hora e fuso convida a comparações que dependem da configuração do servidor. Se o seu sistema precisa registrar o instante do cadastro, mantenha isso em um campo separado.
  • Compare por dia, não por milissegundos. A conta de idade deve arredondar para o dia antes de comparar com o limite. Comparações por intervalo de tempo produzem resultados diferentes para o mesmo par de datas.

Sobre os limites de idade, vale lembrar que eles não vêm todos do mesmo lugar. Treze anos aparece nas regras americanas de proteção de dados de crianças, dezesseis é a idade padrão de consentimento para serviços digitais na Europa, com liberdade para os países membros ajustarem entre treze e dezesseis, dezoito é a maioridade na maioria dos países e vinte e um aparece em situações específicas de consumo de álcool em alguns lugares. São regras de origens diferentes, e tratar todas como um único número global é um erro de projeto.

Ao montar o conjunto de dados, gere registros no gerador de identidade para ter datas plausíveis e varie os casos de borda com valores escritos à mão. Os registros existem apenas para teste e não podem ser usados para se passar por outra pessoa, nem para atravessar nenhuma verificação de idade ou de identidade de verdade.

Próximos passos

Adicione ao seu conjunto de teste, hoje mesmo, os três casos que mais falham: aniversário na data de referência, um dia antes e nascimento em 29 de fevereiro. Se você precisa montar os registros completos, gere-os no gerador de identidade e leia em seguida como tratar a idade no texto sobre teste de verificação de idade, que explica por que o limite deve ser configurável em vez de fixo.

Continue lendo

Artigos sobre Gerador de dados de identidade e testes online