Test di verifica dell'età: soglie, confini e giorni bisestili

Il test di verifica dell’età è la disciplina di verificare che un cancello si apra per le persone giuste e si chiuda per le altre — ed è più difficile di quanto sembri, perché il cancello è un confronto con una soglia che proviene da una regola scritta altrove, applicata a una data di nascita che può essa stessa essere stata registrata in un calendario diverso.

Questo articolo esamina da dove provengono le soglie comuni, cosa possono e non possono stabilire le date di nascita auto-dichiarate, quali valori di confine meritano un test e come gestire le persone per cui l’aritmetica non funziona come previsto.

Da dove vengono le diverse soglie di età?

Provengono da regole diverse con scopi diversi, ed è per questo che non c’è un unico numero da implementare.

L’osservazione importante è che questi non sono quattro punti su un’unica scala. Una piattaforma può dovere un obbligo di privacy rivolto ai minori a una certa età, aver bisogno di un consenso verificato a un’altra, ed essere vietata da un servizio a una terza. Ogni cancello dovrebbe essere implementato come regola a sé con la propria fonte, e il profilo che lo governa dovrebbe essere dichiarato nel codice anziché inferito da un unico numero memorizzato.

Ne seguono due regole pratiche. Non riutilizzare mai una soglia perché ne esiste un’altra altrove nel prodotto, e non trattare mai l’età applicabile più alta come predefinita sicura per ogni funzionalità, perché ciò esclude in silenzio persone che hanno diritto a usare il servizio.

Cosa può stabilire una data di nascita auto-dichiarata?

Molto poco oltre al fatto che qualcuno l’ha digitata. Una data inserita in un modulo senza altri controlli registra un’affermazione, non un fatto, e il suo unico valore reale è che impedisce l’uso improprio accidentale e dà al sistema qualcosa con cui confrontarsi più tardi.

Non è una ragione per saltare il campo, ma è una ragione per essere precisi su a cosa serve. Una data auto-dichiarata supporta un cancello basato sull’onestà: si chiede all’utente, si registra la risposta e il prodotto si affida alla veridicità della risposta. Un cancello più forte ha bisogno di prove di qualche tipo, il che in pratica significa confrontare con un documento o un database anziché con una data digitata.

I due dovrebbero essere modellati diversamente, perché falliscono diversamente. Una data auto-dichiarata può essere sbagliata per negligenza o per dichiarazione deliberatamente falsa, e nessuna quantità di validazione sul modulo può distinguere le due. Un controllo basato su documento può fallire perché il documento non è valido, perché l’aritmetica differisce o perché il controllo non è disponibile nel momento in cui l’utente ne ha bisogno. Registrare quale tipo di cancello ha prodotto una decisione è ciò che rende la decisione verificabile in seguito.

Sotto i tredici anni, la situazione è di nuovo diversa: si applicano regole sul consenso e sulla raccolta dei dati, che è una questione di conformità anziché di verifica, ed è al di fuori di ciò che qualunque validazione di modulo può risolvere. Qualunque cosa faccia il prodotto qui dovrebbe essere una decisione documentata, non un valore predefinito emerso da una regola di validazione.

Come dovrebbero essere testati i valori di confine?

Il test ai confini per questo tipo di regola significa scegliere la data, non la persona. Fissa la data di riferimento che il sistema userà, poi costruisci date di nascita su entrambi i lati di ogni soglia e asserisci l’esito esatto.

• La data di nascita che rende la persona esattamente dell’età soglia alla data di riferimento, che deve passare secondo la convenzione usuale che il compleanno stesso conta.
• La data di nascita un giorno dopo, che la rende un giorno al di sotto e deve fallire.
• La data di nascita un giorno prima, che la colloca un giorno oltre la soglia e deve passare.
• Una data di nascita in un giorno bisestile, con la data di riferimento in un anno non bisestile, dove la regola di confronto conta.
• Una data di nascita all’estremo dell’intervallo plausibile, per intercettare un’aritmetica che presuppone una diffusione ristretta di età.

I primi tre intercettano quasi tutto, e il quarto intercetta le implementazioni che decidono in silenzio che un compleanno in un giorno bisestile è slittato al primo marzo in certi anni. Tutti e cinque hanno bisogno di una data di riferimento fissa; un test che legge l’orologio corrente passa oggi e fallisce intorno a un compleanno, e il guasto arriverà nel giorno di release di qualcuno.

Vale la pena dichiarare esplicitamente di fare il confronto nella direzione che rende il margine più piccolo: la persona ha almeno questa età, anziché questa data è più recente di quella. Formulare la regola come confronto tra date invita a segni invertiti, e un segno invertito su una soglia trasforma un cancello nel suo opposto.

Come cambiano la risposta i fusi orari?

La soglia viene valutata in un istante, e la data di nascita no. Se la data corrente viene presa da un server in un fuso orario mentre l’utente è in un altro, allora per alcune ore ogni giorno i due discordano su quale sia oggi. Chi compie gli anni può essere trattato come un giorno più giovane, o un giorno più vecchio, a seconda dell’orologio consultato.

Per un controllo interattivo, la data locale dell’utente è di solito il riferimento giusto, perché l’utente è colui che sa che giorno è dove si trova. Per un controllo pianificato o in batch, una singola data di riferimento fissa è di solito la scelta giusta, perché il risultato deve essere riproducibile. Ciò che non deve accadere è una commistione: una parte del sistema che usa la data locale e un’altra che usa quella del server, il che produce record che concordano con se stessi solo nella maggior parte dei giorni.

Un’ambiguità correlata riguarda le date di nascita registrate senza una componente oraria. Memorizza una data di calendario semplice e non collegarvi mai un fuso orario, altrimenti lo stesso record significherà giorni diversi in sistemi diversi.

E le persone nate in un giorno bisestile?

Il loro compleanno arriva, secondo la maggior parte delle convenzioni, il primo marzo in un anno non bisestile, oppure l’ultimo giorno di febbraio — e giurisdizioni e sistemi diversi rispondono in modo diverso. La conseguenza per un cancello di età è una finestra di al massimo un giorno in cui le due convenzioni discordano sul fatto che qualcuno abbia raggiunto una soglia.

La risposta pratica non è scegliere una parte e dimenticarsene, ma scegliere deliberatamente e rendere la scelta testabile. Qualunque convenzione adotti il prodotto dovrebbe essere scritta dove viene calcolata l’età e coperta da una fixture, così che un cambiamento successivo a una libreria di date non la inverta in silenzio. Per una soglia con conseguenze reali, una discordanza di un giorno è esattamente il genere di cosa che genera un ricorso, e un ricorso è più facile da rispondere quando la convenzione è documentata.

I valori generati per questo tipo di test sono sintetici ed esistono solo per esercitare il cancello; non sono le date di nascita di persone reali e non possono essere usati per superare alcun controllo reale di età o identità. Il generatore di identità e dati di test produce date di nascita su un’ampia gamma di anni con una chiave di identità fissa, il che rende semplice assemblare un insieme di confine e riprodurlo su richiesta.

Per gli sviluppatori: rendere configurabili le soglie

Leggi ogni soglia dalla configurazione anziché codificarla a mano. Le soglie cambiano, a volte per una singola giurisdizione, e un numero sepolto in un condizionale è a una release di distanza da una lacuna di conformità. Nomina ogni regola in base all’obbligo che implementa, così che un lettore possa capire perché il cancello esiste, non solo che esiste.

Tieni il calcolo dell’età in un unico posto e richiamalo da ogni parte. Due implementazioni della stessa regola derivano, e quella che deriva è sempre quella sul percorso che nessuno rilegge. Prendi la data di riferimento come parametro anziché leggere l’orologio dentro la funzione, così che i test possano fissarla e i job in batch possano passare una propria data fissa.

Memorizza la data di nascita, mai un’età. Un’età è un valore derivato che diventa sbagliato secondo un proprio calendario, e una memorizzata sarà sbagliata per ogni record nella tabella il giorno dopo essere stata scritta. Contrassegna il valore derivato come derivato ovunque venga esposto, così che nessuno inizi a fidarsi di esso come di un fatto memorizzato.

Infine, fai in modo che l’insieme di fixture dimostri i confini. Quattro record — esattamente alla soglia, un giorno al di sotto, un giorno al di sopra e un giorno bisestile — asseriti contro una data fissa intercetteranno la grande maggioranza dei difetti in questo ambito, e continueranno a funzionare per anni perché la data di riferimento è data anziché osservata.

Passi successivi

Scegli il cancello di età con le conseguenze più gravi nel tuo prodotto e scrivi da quale regola proviene; se nessuno sa dirlo, questo è il risultato. Poi costruisci i quattro record di confine, fissa la data di riferimento ed eseguili — qualunque cosa discordi dall’esito atteso è un bug nel confronto anziché nel modulo. La guida sui casi limite della data di nascita copre i problemi di calendario sottostanti, e il generatore di identità fornisce la diffusione più ampia di date di nascita che i test ai confini non raggiungono.