Scegliere i paesi per i dati di test è di solito considerato un compito noioso che segue il lavoro interessante. Qualcuno apre un elenco di tutti i paesi di cui il sistema ha mai sentito parlare, spunta una manciata di nomi familiari e passa oltre. La scelta si cristallizza poi in un insieme di fixture, e la fixture decide silenziosamente cosa la suite può e non può rilevare.
Questo articolo esamina la decisione stessa. Espone tre assi per scegliere un insieme, spiega perché un buon insieme ha bisogno di voci deliberatamente scomode e non solo di quelle popolari, e descrive come mantenere l’insieme sotto controllo di versione affinché un risultato del mese scorso significhi ancora qualcosa oggi.
Perché l’insieme di paesi merita una decisione a sé?
Una singola fixture dimostra che un record può passare. Un insieme di paesi dimostra che le regole vengono applicate dove devono esserlo. Sono affermazioni diverse, e solo la seconda fallisce quando una regola è legata alla regione sbagliata.
Considera una regola che presuppone che un codice postale sia obbligatorio e numerico. Un record proveniente da un paese che soddisfa questo presupposto ti dice che la regola viene eseguita. Non ti dice nulla sui paesi in cui il presupposto è falso, e il guasto emergerà in produzione invece che nella suite. L’insieme è lo strumento che rende visibile questa classe di lacune, ed è per questo che merita la stessa revisione dello schema che esercita.
L’insieme è anche la documentazione più economica che un team possa lasciare dietro di sé. Un collega che sa leggere l’elenco vede quali convenzioni la suite dichiara di conoscere e quali ha invece accettato silenziosamente di ignorare.
Tre assi: raggiungibilità, difficoltà dei dati, valore limite
La maggior parte dei dibattiti su un elenco di paesi riguarda in realtà quale asse conti. Nominarli separatamente costituisce la maggior parte del lavoro.
| Asse | La domanda che pone | Cosa rileva |
|---|---|---|
| Raggiungibilità commerciale | Possiamo davvero servire questo paese? | Ramificazioni di pagamento, consegna, regolamento e lingua che non vengono mai eseguite |
| Difficoltà dei dati | Quanto sono scomodi i dati stessi? | Set di caratteri, direzione di scrittura, lunghezza dei campi e presupposti di analisi |
| Valore limite | Spinge un limite fino all’estremo? | Troncamento, overflow del layout e limiti fuori di uno |
Un insieme che segue solo il primo asse è un elenco di mercati. È un punto di partenza ragionevole e un traguardo mediocre, perché i casi scomodi si concentrano esattamente dove non c’è fatturato che li giustifichi.
Cosa rende buono un campione limite?
Un campione limite merita il suo posto perché è il caso più lungo, il più piccolo o il meno collaborativo per un campo specifico. Il nome di paese che deve stare nella colonna più stretta, il nome di suddivisione che deve entrare in un’etichetta stampata, la riga di indirizzo che deve stare dentro un riquadro fisso: nessuna di queste è una curiosità. Sono gli input che rivelano una larghezza fissa.
L’abitudine utile è abbinare ogni limite all’asserzione che dovrebbe far fallire. Se un campo è dimensionato per un indirizzo comodo e l’insieme contiene un indirizzo tutt’altro che comodo, la voce ha una ragione di esistere. Se ogni voce è comodamente breve, il layout non è testato, non importa quante voci ci siano.
Ampiezza e profondità non sono sostituti l’una dell’altra. Venti paesi simili esercitano lo stesso percorso di codice venti volte; tre estremi ben scelti ne esercitano tre diversi.
Come si gestiscono i paesi in cui un campo non si applica?
Alcuni paesi non hanno alcun sistema di codice postale, e alcuni non hanno un livello di suddivisione che corrisponda al campo che un formulario impone. Questi non sono dati mancanti. Sono la forma dei dati, e un insieme che li omette produce una suite che tratta un indirizzo corretto come uno non valido.
La distinzione da tenere a mente è quella tra un valore assente perché il campo non è applicabile e un valore assente perché nessuno l’ha fornito. Solo il secondo è un difetto. Quando un formulario rende tale campo obbligatorio ovunque, l’insieme di paesi è l’unica cosa che lo rivela: il caso che fallisce non può nemmeno essere scritto senza un paese in cui il campo non esiste davvero.
Dove un altro articolo copre già la forma di un campo paese per paese, mantieni questo ristretto e passa il lettore. La guida ai formati dei codici postali per paese è la destinazione giusta per sapere come appare un codice; la domanda qui è solo se l’insieme contenga una voce per cui quella domanda è priva di senso.
Di cosa è solitamente fatto un insieme predefinito
Un insieme che sopravvive al contatto con un team reale tende ad assestarsi su tre gruppi, e ciascun gruppo svolge un lavoro che gli altri non possono fare.
- Il paese d’origine, o il luogo in cui si sono formate la maggior parte dei presupposti del team. È la linea di base rispetto alla quale tutto il resto appare strano.
- I mercati principali, scelti per le ramificazioni che esercitano: consegna, pagamento, regolamento e contenuti.
- Un piccolo numero di estremi, scelti perché infrangono un limite e non perché qualcuno spedisca lì.
Il terzo gruppo è quello che viene tagliato quando una suite viene ridotta per la velocità, ed è quello che andrebbe tagliato per ultimo. Una suite che viene eseguita rapidamente e perde ogni difetto di troncamento non è veloce, è cieca.
Per gli sviluppatori: trattare l’insieme come un asset versionato
La raccomandazione pratica è smettere di trattare l’elenco dei paesi come configurazione e iniziare a trattarlo come un asset con una propria identità.
Dai all’insieme un nome e una versione, e memorizza quell’identificatore accanto alle fixture che ne dipendono. Quando l’insieme cambia, cambia anche il significato di ogni asserzione scritta rispetto a esso, e senza un identificatore non c’è modo di distinguere una regressione da una ridefinizione. Un risultato memorizzato è interpretabile solo se puoi recuperare l’insieme su cui è stato eseguito.
Mantieni il ragionamento nel repository, accanto all’elenco. Per ogni voce, annota l’asse per cui è stata scelta e l’asserzione che dovrebbe sostenere, così la prossima persona che ridurrà l’elenco saprà cosa sta rimuovendo.
Popola l’insieme con valori costruiti. Le fixture non dovrebbero mai contenere i dettagli di una persona reale, e un insieme assemblato da record reali è sia un problema di privacy sia un problema di riproducibilità. La directory dei paesi e delle regioni è un buon posto per rivedere come ogni paese e regione è descritto prima di convalidare una voce, e una singola pagina di paese come la voce degli Stati Uniti mostra come appaiono le note di un paese quando sono tenute insieme in un unico posto.
Un avvertimento copre tutto quanto sopra. Gli elenchi di paesi, i nomi delle regioni e i valori di esempio usati in questo articolo sono esempi sintetici costruiti per illustrare una decisione di test del software. Non descrivono alcuna organizzazione reale, alcun set di dati reale e alcuna persona reale, e non sono adatti come prova per nulla al di fuori di un ambiente di test.
Passi successivi
Prendi l’insieme di fixture che stai usando oggi e contrassegna ogni voce con l’asse per cui è stata scelta. Le voci che non rientrano in alcun asse sono candidate alla rimozione, e gli assi senza voce sono le lacune da colmare per prime. Poi annota, per ogni voce, l’asserzione che protegge. La guida alla copertura dei dati dei paesi trasforma quell’elenco in qualcosa di verificabile, e la guida alla freschezza dei dati dei paesi affronta cosa succede quando una voce smette di essere accurata.