Tests de vérification d'âge : seuils, frontières et jours bissextiles

Les tests de vérification d’âge sont la discipline consistant à vérifier qu’une barrière s’ouvre pour les bonnes personnes et se ferme pour les autres — et c’est plus difficile qu’il n’y paraît, car la barrière est une comparaison à un seuil qui provient d’une règle écrite ailleurs, appliquée à une date de naissance qui a peut-être elle-même été enregistrée dans un autre calendrier.

Cet article examine d’où proviennent les seuils courants, ce que des dates de naissance auto-déclarées peuvent et ne peuvent pas établir, quelles valeurs frontières méritent un test, et comment gérer les personnes pour lesquelles l’arithmétique ne fonctionne pas comme prévu.

D’où viennent les différents seuils d’âge ?

Ils proviennent de règles différentes ayant des objectifs différents, ce qui explique qu’il n’existe pas de nombre unique à implémenter.

L’observation importante est que ce ne sont pas quatre points sur une même échelle. Une plateforme peut devoir une obligation de confidentialité relative aux enfants à un âge, avoir besoin d’un consentement vérifié à un autre, et se voir interdire un service à un troisième. Chaque barrière devrait être implémentée comme sa propre règle avec sa propre source, et le profil qui la régit devrait être énoncé dans le code plutôt que déduit d’un nombre stocké unique.

Deux règles empiriques s’ensuivent. Ne réutilisez jamais un seuil parce qu’un autre existe ailleurs dans le produit, et ne traitez jamais l’âge applicable le plus élevé comme une valeur par défaut sûre pour toutes les fonctionnalités, car cela exclut discrètement des personnes qui ont le droit d’utiliser le service.

Qu’est-ce qu’une date de naissance auto-déclarée peut établir ?

Très peu de choses au-delà du fait que quelqu’un l’a saisie. Une date saisie dans un formulaire sans autre contrôle enregistre une déclaration, et non un fait, et sa seule valeur réelle est d’empêcher un usage abusif accidentel et de donner au système quelque chose à comparer plus tard.

Ce n’est pas une raison de sauter le champ, mais c’est une raison d’être précis sur sa finalité. Une date auto-déclarée prend en charge une barrière fondée sur l’honnêteté : on demande à l’utilisateur, on enregistre sa réponse, et le produit compte sur la véracité de cette réponse. Une barrière plus forte a besoin d’une preuve quelconque, ce qui, en pratique, signifie comparer à un document ou à une base de données plutôt qu’à une date saisie.

Les deux devraient être modélisées différemment, car elles échouent différemment. Une date auto-déclarée peut être fausse par négligence ou par déclaration délibérément inexacte, et aucune validation du formulaire ne peut distinguer les deux. Un contrôle adossé à un document peut échouer parce que le document est invalide, parce que l’arithmétique diffère, ou parce que le contrôle est indisponible au moment où l’utilisateur en a besoin. Consigner quel type de barrière a produit une décision est ce qui rend la décision auditable plus tard.

En dessous de treize ans, la situation est encore différente : des règles de consentement et de collecte de données s’attachent, ce qui est une question de conformité plutôt qu’une question de vérification, et cela dépasse ce que la validation d’un formulaire peut trancher. Ce que le produit fait ici devrait être une décision documentée, et non une valeur par défaut née d’une règle de validation.

Comment les valeurs frontières doivent-elles être testées ?

Tester les frontières pour ce type de règle signifie choisir la date, et non la personne. Figez la date de référence que le système utilisera, puis construisez des dates de naissance des deux côtés de chaque seuil et affirmez le résultat exact.

• La date de naissance qui rend la personne exactement à l’âge seuil à la date de référence, qui doit passer selon la convention habituelle où l’anniversaire lui-même compte.
• La date de naissance un jour plus tard, qui la laisse à un jour du seuil et doit échouer.
• La date de naissance un jour plus tôt, qui la place un jour au-delà du seuil et doit passer.
• Une date de naissance un jour bissextile, avec la date de référence dans une année non bissextile, où la règle de comparaison compte.
• Une date de naissance à l’extrémité de la plage plausible, pour intercepter une arithmétique qui suppose une étroite répartition des âges.

Les trois premières interceptent presque tout, et la quatrième intercepte les implémentations qui décident discrètement qu’un anniversaire du jour bissextile a glissé au premier mars certaines années. Toutes les cinq ont besoin d’une date de référence fixe ; un test qui lit l’horloge courante passe aujourd’hui et échoue autour d’un anniversaire, et la défaillance tombera le jour de publication de quelqu’un.

Effectuer la comparaison dans le sens qui rend la frontière la plus petite mérite d’être énoncé explicitement : la personne a-t-elle au moins cet âge, plutôt que cette date est-elle plus jeune que celle-là. Formuler la règle comme une comparaison entre deux dates invite à inverser les signes, et un signe inversé sur un seuil transforme une barrière en son contraire.

Comment les fuseaux horaires changent-ils la réponse ?

Le seuil est évalué à un instant, et la date de naissance ne l’est pas. Si la date courante est prise sur un serveur d’un fuseau horaire tandis que l’utilisateur est dans un autre, alors pendant quelques heures chaque jour les deux sont en désaccord sur le jour qu’on est. Quelqu’un dont c’est l’anniversaire peut être traité comme un jour plus jeune, ou un jour plus vieux, selon l’horloge consultée.

Pour un contrôle interactif, la date locale de l’utilisateur est généralement la bonne référence, car c’est l’utilisateur qui sait quel jour on est là où il se trouve. Pour un contrôle planifié ou par lots, une date de référence fixe unique est généralement la bonne, car le résultat doit être reproductible. Ce qui ne doit pas se produire, c’est un mélange : une partie du système utilisant la date locale et une autre celle du serveur, ce qui produit des enregistrements qui s’accordent avec eux-mêmes seulement la plupart des jours.

Une ambiguïté connexe concerne les dates de naissance enregistrées sans composante horaire. Stockez une date de calendrier simple et ne lui attachez jamais de fuseau horaire, sinon le même enregistrement signifiera des jours différents dans des systèmes différents.

Qu’en est-il des personnes nées un jour bissextile ?

Leur anniversaire tombe, selon la plupart des conventions, le premier mars d’une année non bissextile, ou le dernier jour de février — et différentes juridictions et différents systèmes répondent à cela différemment. La conséquence pour une barrière d’âge est une fenêtre d’au plus un jour durant laquelle les deux conventions sont en désaccord sur la question de savoir si quelqu’un a atteint un seuil.

La réponse pratique n’est pas de choisir un camp et de l’oublier, mais de choisir délibérément et de rendre le choix testable. Quelle que soit la convention adoptée par le produit, elle devrait être écrite là où l’âge est calculé et couverte par une fixture, afin qu’un changement ultérieur dans une bibliothèque de dates ne l’inverse pas en silence. Pour un seuil aux conséquences réelles, un désaccord d’un jour est exactement le genre de chose qui génère un recours, et un recours est plus facile à instruire lorsque la convention est documentée.

Les valeurs générées pour ce type de test sont synthétiques et n’existent que pour exercer la barrière ; ce ne sont pas les dates de naissance de vraies personnes, et elles ne peuvent pas servir à passer un contrôle réel d’âge ou d’identité. Le générateur d’identités et de données de test produit des dates de naissance sur une large plage d’années avec une clé d’identité fixe, ce qui rend simple l’assemblage d’un ensemble de frontières et sa reproduction à la demande.

Pour les développeurs : rendre les seuils configurables

Lisez chaque seuil depuis la configuration plutôt que de le coder en dur. Les seuils changent, parfois pour une seule juridiction, et un nombre enfoui dans un conditionnel est à une publication d’une lacune de conformité. Nommez chaque règle d’après l’obligation qu’elle met en œuvre afin qu’un lecteur puisse dire pourquoi la barrière existe, et pas seulement qu’elle existe.

Gardez le calcul de l’âge en un seul endroit et appelez-le de partout. Deux implémentations de la même règle dérivent, et celle qui dérive est toujours celle du chemin que personne ne relit. Prenez la date de référence comme paramètre plutôt que de lire l’horloge à l’intérieur de la fonction, afin que les tests puissent la figer et que les traitements par lots puissent passer leur propre date fixe.

Stockez la date de naissance, jamais un âge. Un âge est une valeur dérivée qui devient fausse selon son propre calendrier, et un âge stocké sera faux pour chaque enregistrement de la table le lendemain de son écriture. Marquez la valeur dérivée comme dérivée partout où elle est exposée, afin que personne ne commence à s’y fier comme à un fait stocké.

Enfin, faites prouver les frontières à l’ensemble de fixtures. Quatre enregistrements — exactement au seuil, un jour en moins, un jour au-delà, et un jour bissextile — affirmés contre une date fixe intercepteront la grande majorité des défauts dans ce domaine, et ils continuent de fonctionner pendant des années parce que la date de référence est donnée plutôt qu’observée.

Étapes suivantes

Choisissez la barrière d’âge aux conséquences les plus élevées dans votre produit et notez de quelle règle elle provient ; si personne ne peut le dire, c’est là la conclusion. Construisez ensuite les quatre enregistrements frontières, figez la date de référence et exécutez-les — tout ce qui est en désaccord avec le résultat attendu est un bug dans la comparaison et non dans le formulaire. Le guide sur les cas limites de date de naissance couvre les problèmes de calendrier sous-jacents, et le générateur d’identités fournit la répartition plus large des dates de naissance que les tests de frontières n’atteignent pas.