Accueil / Vérifier ce qu'il rend

Testez le vérificateur avant de croire son verdict

Un contrôle qui rend un chiffre plausible n'est pas la même chose qu'un contrôle qui rend un chiffre juste, et un contrôle défaillant échoue rarement de façon bruyante, il rend un résultat qui a l'air correct.

Un script écrit pour mesurer quelque chose, un nombre de problèmes, de caractères qui correspondent à un motif, de fichiers mal nommés, s'exécute et affiche un chiffre qui paraît plausible. Un chiffre plausible et un chiffre correct ne sont pas la même chose, et l'écart entre les deux ne s'annonce presque jamais de lui-même.

Cinq bugs, cinq chiffres faux et convaincants

Lors d'un seul audit, cinq mesures écrites maison se sont révélées fausses, chacune pour une raison différente. Une vérification de répertoire renvoyait faux sur un lien symbolique valide, comme si le dossier lié n'existait pas. Une comparaison au niveau des octets comptait mal les caractères accentués, composés de plusieurs octets. Une opération de regroupement ignorait la casse et fusionnait des éléments qui auraient dû rester distincts. Un marqueur d'ordre des octets injecté en tête de fichier faussait toute lecture ultérieure, et une expression régulière mal calée sur les fins de ligne sautait du contenu. Aucune des cinq erreurs ne s'est annoncée : chacune a produit un chiffre raisonnable, et chacune était fausse.

Ce que le point d'une expression régulière franchit vraiment

Le cas des fins de ligne se mesure plutôt qu'il ne se suppose. En JavaScript, par défaut, le point d'une expression régulière ne franchit aucun saut de ligne, ni le simple retour à la ligne des systèmes Unix ni la paire de caractères que Windows utilise. Le script pointe.js compare les deux, sur un fichier de chaque style.

node pointe.js unix.txt
point simple, sans drapeau s : false
point simple, drapeau s      : true
deux points, drapeau s       : false

node pointe.js windows.txt
point simple, sans drapeau s : false
point simple, drapeau s      : false
deux points, drapeau s       : true

Le piège propre à Windows n'apparaît qu'une fois le drapeau qui autorise le point à franchir les sauts de ligne activé : une fin de ligne Windows compte pour deux caractères, un retour chariot et un saut de ligne, et un seul point n'en couvre qu'un des deux. Sur un fichier Unix, ce même drapeau suffit puisqu'il n'y a qu'un caractère à franchir. Un auto-test qui inclut du contenu à cheval sur une fin de ligne Windows, avec le drapeau actif, attrape l'erreur que la même entrée en fin de ligne Unix ne peut pas révéler.

L'auto-test, avant de faire confiance

Le correctif coûte quelques minutes et doit tourner avant la première sortie réelle d'un script de mesure. Donnez-lui une entrée fabriquée qu'il doit absolument signaler, et une entrée propre qu'il ne doit absolument pas signaler. Faites couvrir à ces deux cas les particularités réelles de votre terrain : fins de ligne différentes, caractères accentués, liens symboliques, casse mixte. Un script incapable de classer correctement ses propres cas de test à réponse connue ne mérite aucune confiance sur des données réelles, quelle que soit la plausibilité de son chiffre.

Compter aussi les fausses alertes

Un vérificateur de liens morts a un jour signalé un lot de problèmes dont la figure qui accompagne cette leçon donne le compte exact et la part réellement fondée. La plupart des signalements venaient d'une incohérence de nommage que le vérificateur n'avait pas prévue, et deux bugs distincts de faux positifs se cachaient sous ce bruit : un marqueur d'ordre des octets pris pour un bloc de métadonnées manquant, et un exemple entre guillemets dans un bloc de code pris pour une véritable violation de style. Ces deux bugs n'ont été trouvés qu'en testant le détecteur contre des cas connus, jamais en scrutant sa sortie plus attentivement. Une fausse accusation coûte autant de confiance qu'un défaut manqué : mesurez le taux de faux positifs d'un détecteur, pas seulement ce qu'il attrape.

Faire écrire au programme lui-même son fichier de sortie évite le marqueur d'ordre des octets : sur PowerShell 5.1, la redirection et Out-File en insèrent un, invisible ; Set-Content n'en ajoute aucun mais écrit en encodage local, cassant les accents (E9, E0, E7). Remède : écriture explicite en UTF-8 sans marqueur, via WriteAllText et UTF8Encoding($false). Ce principe rejoint un vert ne prouve rien tant qu'il n'a pas été prouvé lui-même : un contrôle qui n'a pas fait ses preuves sur des cas connus ne mérite aucun crédit sur des cas réels.