Les fixtures d’analyse de CV sont la petite bibliothèque de documents qu’une équipe conserve pour qu’un analyseur puisse être testé contre autre chose que le fichier que quelqu’un avait ouvert par hasard. C’est la partie la moins glamour d’un système de recrutement et celle qui décide si les défauts d’analyse sont attrapés lors d’une exécution de test ou en production.
Cet article couvre pourquoi le problème de format ne peut pas être résolu en choisissant une norme, quelles mises en page cassent réellement les analyseurs, comment organiser les fixtures pour qu’une défaillance pointe vers une cause, et pourquoi un ensemble de fixtures n’est jamais terminé.
Pourquoi n’existe-t-il pas de format standard pour un CV ?
Parce que rien dans le processus n’en exige un. Un CV est un document qu’une personne écrit pour être lu par un humain, dans l’outil qu’elle possède, et les outils n’imposent aucune structure partagée. Un fichier de traitement de texte avec une mise en page à deux colonnes, un export texte depuis un profil en ligne, une impression numérisée, une présentation en forme de diaporama — tout cela arrive dans la même boîte de réception et tout cela est légitime.
L’absence de norme n’est pas un oubli que de meilleurs outils combleront, car les incitations vont dans l’autre sens. La personne qui écrit le CV optimise pour l’impression qu’un lecteur humain se forme dans les premières secondes. La personne qui le lit optimise pour ce qu’elle peut extraire rapidement. Ni l’une ni l’autre n’a de raison de contraindre la mise en page pour convenir à un analyseur.
Voilà la prémisse sur laquelle repose toute la stratégie de test. L’objectif n’est pas la conformité à un format, car il n’existe aucun format auquel se conformer. L’objectif est de récupérer les bons champs dans des documents dont personne ne contrôle la mise en page.
Quelles variantes de mise en page les tests d’analyse doivent-ils couvrir ?
Celles qui déplacent le contenu. L’ordre, les colonnes et la proximité entre une étiquette et sa valeur sont ce qui casse l’extraction, bien plus souvent que des polices inhabituelles ou un format de page différent.
| Variante de mise en page | Ce qu’elle casse |
|---|---|
| Corps à deux colonnes | L’ordre de lecture est perdu, si bien qu’une date de la colonne de droite se rattache à un poste de la colonne de gauche |
| Titres de section dans un ordre inhabituel | Un analyseur qui attend la formation en premier n’enregistre rien pour les entrées qui viennent plus tard |
| Expérience rédigée en prose | Aucune structure de bloc répétée, si bien qu’un analyseur qui en a besoin n’en trouve aucune |
| Compétences sous forme de rangée d’étiquettes | Les éléments s’enchaînent sans séparateurs, et le découpage entre eux est inventé |
| Tableaux utilisés pour la mise en page | Un poste, un employeur et une date se trouvent dans trois cellules sans relation sémantique |
| Dates sous une forme non numérique | Les noms de mois, les libellés saisonniers et les formulations approximatives déjouent la correspondance numérique |
| En-têtes et pieds de page | Les coordonnées sont dupliquées sur chaque page et peuvent écraser les vraies |
Un second axe compte tout autant : sur quelles pages se trouvent les coordonnées, et si le document a une variante ou deux. Un CV exporté deux fois depuis le même outil avec une langue changée aura les titres de section dans une langue différente, et un analyseur qui se base sur ces titres n’extraira silencieusement rien du second export.
Les fixtures doivent-elles être organisées par scénario ou par numéro ?
Par scénario, toujours. Le numéro ne vous dit rien quand un test échoue, et le scénario vous dit presque tout.
Une fixture nommée d’après ce qu’elle contient — une mise en page à deux colonnes, une rangée d’étiquettes de compétences, une section expérience rédigée en paragraphe — est auto-documentée. Quand elle échoue, le nom est une hypothèse sur l’endroit où l’analyseur a cassé. Une fixture nommée avec un index ou une date est une référence qui doit être résolue via un second document avant tout débogage, et ce second document est toujours périmé.
L’organisation détermine aussi ce qui manque. Une bibliothèque triée par scénario montre ses propres lacunes d’un coup d’œil : s’il n’y a aucune fixture pour un document sans section formation, alors ce cas n’a jamais été testé, et l’absence est visible. Une bibliothèque triée par numéro de fichier masque complètement la même absence.
Un second avantage compte pour la maintenance. Les noms de scénario survivent aux changements de l’analyseur. Quand l’implémentation est réécrite, la bibliothèque de fixtures décrit toujours les formes que prennent les vrais documents, ce qui est la partie qui ne change pas.
Pourquoi la génération aléatoire rend-elle les défaillances non reproductibles ?
Parce qu’une entrée aléatoire n’est l’enregistrement de rien. Quand un test échoue contre un document généré aléatoirement, la défaillance existe dans une exécution et nulle part ailleurs, et le seul moyen d’enquêter est de modifier le générateur pour qu’il reproduise le cas — c’est-à-dire de le transformer en fixture.
Ce n’est pas un argument contre la génération aléatoire, qui est réellement douée pour trouver des formes inattendues. C’est un argument sur le côté de la frontière auquel appartient chaque outil. La génération aléatoire appartient à la phase exploratoire, où l’objectif est de découvrir un cas auquel personne n’a pensé. Dès qu’un cas est découvert, il cesse d’être aléatoire et devient une fixture, avec l’entrée figée et la sortie attendue enregistrée. La régression est alors verrouillée sur un cas qui existe.
Il y a un problème plus subtil à faire avancer la génération aléatoire dans la suite de régression. Un document généré aléatoirement varie dans toutes les dimensions à la fois, si bien qu’une défaillance qui en découle ne peut être attribuée à aucune en particulier. Une fixture de scénario fait varier une dimension délibérément, et la défaillance qu’elle produit nomme sa propre cause.
Comment les fixtures se dégradent-elles ?
Lentement, et de trois manières faciles à manquer parce que chacune ne ressemble à rien du tout.
Les documents réels qu’elles imitent changent : les modèles sont repensés, une mise en page courante il y a cinq ans cesse d’apparaître, et une nouvelle prend sa place. La fixture continue de passer et continue de couvrir une forme que plus personne ne soumet. Les langues dérivent : un ensemble de fixtures construit dans une langue teste la correspondance des étiquettes dans cette langue seulement, et ajouter une seconde langue n’est pas un changement de fixture mais l’ajout de tout un ensemble parallèle. Et les attentes pourrissent face à l’analyseur : une assertion écrite contre une version précoce de la logique d’extraction peut encoder un comportement qui a été corrigé par la suite, si bien que le test impose désormais un bug connu.
Aucun de ces cas n’est détecté par la suite elle-même, car chaque fixture passe encore. La dégradation se trouve par la revue : rouvrir périodiquement la bibliothèque et demander si chaque fixture ressemble encore à quelque chose de réel, si chaque langue prise en charge en a une, et si chaque assertion décrit encore le comportement que vous voulez.
Pour les développeurs : forme des fixtures et champs attendus
Gardez l’entrée et l’attente ensemble, et gardez l’attente étroite.
Une fixture est une paire : le document, et les champs que l’analyseur devrait en renvoyer. Les garder au même endroit signifie qu’un changement d’attente est revu à côté de la forme qui l’a causé. Gardez la valeur attendue lisible plutôt qu’encodée, afin qu’un relecteur puisse voir qu’une date est censée tomber dans un mois précis sans d’abord résoudre un numéro de série.
Quatre pratiques évitent la plupart des ennuis. Vérifiez les champs que la mise en page est conçue pour mettre sous tension, et laissez le reste de l’extraction contrôlé de façon souple, afin qu’une fixture ne soit pas cassée par une amélioration sans rapport ailleurs. Consignez l’origine de chaque fixture dans une ligne de prose — construite à cette fin, mise en page calquée sur une forme courante, aucun document réel utilisé — afin que personne n’ait plus tard à deviner si un fichier vient d’un endroit sensible. Versionnez les fixtures avec l’analyseur pour qu’il soit possible de dire avec quel ensemble un résultat donné a été produit. Et gardez une lacune délibérée dans la bibliothèque pour le cas que vous savez non pris en charge, documentée plutôt que silencieusement absente, car une lacune connue est une décision et une lacune inconnue est un défaut.
Tout ce qu’une fixture contient devrait être construit dans ce but. Les documents d’exemple et les champs attendus décrits ici sont des échantillons construits qui ne contiennent aucun contenu tiré d’un CV réel, et ils existent pour exercer la logique d’analyse plutôt que pour représenter quiconque.
Étapes suivantes
Choisissez trois fixtures de votre ensemble existant et renommez-les afin que le nom décrive la mise en page plutôt qu’un index. L’exercice révèle presque toujours que deux d’entre elles sont le même scénario en double et qu’une évidente manque entièrement. Les cas de formulaire de recrutement qui consomment la sortie analysée constituent l’autre moitié de la même surface de test, et si l’objectif est le volume plutôt que les mises en page, le guide sur l’alimentation d’une base de préproduction le couvre à grande échelle. Quand vous avez besoin de documents pour construire la bibliothèque, l’outil de profil de carrière produit le dossier sous-jacent dont les fixtures devraient attendre les champs.