Fixture per il parsing dei curriculum che restano utili

Le fixture per il parsing dei curriculum sono la piccola libreria di documenti che un team conserva perché un parser possa essere testato contro qualcosa di diverso dal file che qualcuno si trovava aperto. Sono la parte meno appariscente di un sistema di assunzione e la parte che decide se i difetti di parsing vengono catturati in una esecuzione di test o in produzione.

Questo articolo illustra perché il problema del formato non può essere risolto scegliendo uno standard, quali impaginazioni rompono davvero i parser, come organizzare le fixture perché un fallimento indichi una causa e perché un insieme di fixture non è mai finito.

Perché non esiste un formato standard per un CV?

Perché nulla nel processo ne richiede uno. Un CV è un documento che una persona scrive per essere letto da un essere umano, con qualunque strumento abbia, e gli strumenti non impongono alcuna struttura condivisa. Un file di videoscrittura con impaginazione a due colonne, un’esportazione testuale da un profilo online, una stampa scansionata, una presentazione a forma di slide — tutti questi arrivano nella stessa casella di posta e tutti sono legittimi.

L’assenza di uno standard non è una svista che strumenti migliori colmeranno, perché gli incentivi vanno nella direzione opposta. Chi scrive il CV sta ottimizzando per l’impressione che un lettore umano si forma nei primi secondi. Chi lo legge sta ottimizzando per qualunque cosa riesca a estrarre rapidamente. Nessuno dei due ha motivo di vincolare l’impaginazione per andare incontro a un parser.

Questa è la premessa su cui poggia l’intera strategia di test. L’obiettivo non è la conformità al formato, perché non c’è alcun formato a cui conformarsi. L’obiettivo è richiamare i campi giusti da documenti la cui impaginazione nessuno controlla.

Quali varianti di impaginazione dovrebbero coprire i test di parsing?

Quelle che spostano il contenuto. Ordine, colonne e vicinanza tra un’etichetta e il suo valore sono ciò che rompe l’estrazione, molto più spesso di caratteri insoliti o di un formato di pagina diverso.

Un secondo asse conta altrettanto: su quali pagine vivono i dati di contatto e se il documento abbia una variante o due. Un CV esportato due volte dallo stesso strumento con una lingua cambiata avrà i titoli di sezione in una lingua diversa, e un parser che si basa su quei titoli estrarrà silenziosamente nulla dalla seconda esportazione.

Le fixture vanno organizzate per scenario o per numero?

Per scenario, sempre. Il numero non ti dice nulla quando un test fallisce, e lo scenario ti dice quasi tutto.

Una fixture nominata per ciò che contiene — un’impaginazione a due colonne, una riga di etichette di competenze, una sezione di esperienza scritta come paragrafo — è auto-documentante. Quando fallisce, il nome è un’ipotesi su dove il parser si è rotto. Una fixture nominata con un indice o una data è una ricerca che deve essere risolta attraverso un secondo documento prima che qualsiasi debug possa iniziare, e quel secondo documento è sempre obsoleto.

L’organizzazione determina anche ciò che manca. Una libreria ordinata per scenario mostra le proprie lacune a colpo d’occhio: se non c’è una fixture per un documento senza sezione formativa, allora quel caso non è mai stato testato, e l’assenza è visibile. Una libreria ordinata per numero di file nasconde la stessa assenza completamente.

C’è un secondo beneficio che conta per la manutenzione. I nomi di scenario sopravvivono ai cambiamenti del parser. Quando l’implementazione viene riscritta, la libreria di fixture descrive ancora le forme che i documenti reali assumono, che è la parte che non cambia.

Perché la generazione casuale rende i fallimenti non riproducibili?

Perché un input casuale non è il record di nulla. Quando un test fallisce contro un documento generato casualmente, il fallimento esiste in una esecuzione e in nessun’altra, e l’unico modo di indagare è modificare il generatore perché riproduca il caso — cioè trasformarlo in una fixture.

Non è un argomento contro la generazione casuale, che è davvero brava a trovare forme inaspettate. È un argomento su da quale lato del confine stia ciascuno strumento. La generazione casuale appartiene alla fase esplorativa, dove l’obiettivo è scoprire un caso a cui nessuno ha pensato. Nel momento in cui un caso viene scoperto, smette di essere casuale e diventa una fixture, con l’input congelato e l’output atteso registrato. La regressione è quindi bloccata a un caso che esiste.

C’è un problema più sottile nel far avanzare la generazione casuale nella suite di regressione. Un documento generato casualmente varia in ogni dimensione contemporaneamente, quindi un fallimento che ne derivi non può essere attribuito a una singola dimensione. Una fixture di scenario varia una dimensione deliberatamente, e il fallimento che produce nomina la propria causa.

Come decadono le fixture?

Lentamente, e in tre modi facili da mancare perché ciascuno sembra non essere nulla.

I documenti reali che imitano cambiano: i modelli vengono ridisegnati, un’impaginazione comune cinque anni fa smette di comparire e una nuova prende il suo posto. La fixture continua a passare e continua a coprire una forma che nessuno invia più. Le lingue derivano: un insieme di fixture costruito in una lingua verifica la corrispondenza delle etichette solo in quella lingua, e aggiungere una seconda lingua non è un cambiamento a una fixture ma l’aggiunta di un intero insieme parallelo. E le attese marciscono contro il parser: un’asserzione scritta contro una versione iniziale della logica di estrazione può codificare un comportamento che è stato corretto in seguito, quindi il test ora impone un bug noto.

Nessuno di questi viene rilevato dalla suite stessa, perché ogni fixture continua a passare. Il decadimento si trova con la revisione: riaprire periodicamente la libreria e chiedersi se ogni fixture assomigli ancora a qualcosa di reale, se ogni lingua supportata ne abbia una e se ogni asserzione descriva ancora il comportamento che vuoi.

Per gli sviluppatori: forma delle fixture e campi attesi

Tieni insieme l’input e l’attesa, e tieni l’attesa ristretta.

Una fixture è una coppia: il documento e i campi che il parser dovrebbe restituire da esso. Tenerli nello stesso posto significa che un cambiamento a un’attesa viene revisionato accanto alla forma che l’ha causato. Mantieni il valore atteso leggibile invece che codificato, così un revisore può vedere che ci si aspetta che una data finisca in un determinato mese senza prima risolvere un numero seriale.

Quattro pratiche prevengono la maggior parte del dolore. Verifica i campi che l’impaginazione è progettata per stressare, e lascia il resto dell’estrazione controllato in modo lasco, così una fixture non si rompe per un miglioramento non correlato altrove. Registra l’origine di ogni fixture in una riga di prosa — costruita per questo scopo, impaginazione modellata su una forma comune, nessun documento reale usato — così che nessuno debba poi indovinare se un file provenga da qualche parte sensibile. Versiona le fixture insieme al parser, così è possibile capire con quale insieme sia stato prodotto un dato risultato. E mantieni una lacuna deliberata nella libreria per il caso che sai non essere supportato, documentata invece che silenziosamente assente, perché una lacuna nota è una decisione e una lacuna ignota è un difetto.

Tutto ciò che una fixture contiene dovrebbe essere costruito per lo scopo. I documenti campione e i campi attesi descritti qui sono campioni costruiti che non contengono alcun contenuto tratto da CV reali, ed esistono per esercitare la logica di parsing più che per rappresentare qualcuno.

Prossimi passi

Scegli tre fixture dal tuo insieme esistente e rinominale in modo che il nome descriva l’impaginazione invece che un indice. L’esercizio rivela quasi sempre che due di esse sono lo stesso scenario ripetuto due volte e che una ovvia manca del tutto. I casi dei moduli di assunzione che consumano l’output analizzato sono l’altra metà della stessa superficie di test, e se l’obiettivo è il volume più che le impaginazioni, la guida su come popolare un database di staging lo copre su larga scala. Quando ti servono documenti da cui costruire la libreria, lo strumento per i profili professionali produce il record sottostante i cui campi le fixture dovrebbero attendersi.