FeedMender

FeedMender/Comment nous le savons

Preuves

Comment les contrôles sont prouvés

Un contrôle écrit, documenté et facturé, mais qui ne se déclenche jamais réellement : voilà le défaut que ce projet a mis le plus d'énergie à éradiquer. Chaque contrôle doit donc démontrer qu'il peut se déclencher sur un fichier réel avant d'être autorisé à compter, et le nombre lui-même est lu depuis le code plutôt que saisi à la main.

Le nombre n'est pas saisi à la main

Il existe 225 contrôles distincts. Ce chiffre n'est pas écrit dans cette page : il est lu depuis la source au moment du build, à partir du même registre auquel la suite de tests se tient elle-même. Un nombre saisi à la main est une affirmation que personne ne revérifie, et chaque audit interne de ce projet en a trouvé un devenu obsolète. Le nombre affiché sur la liste complète des contrôles est donc généré par un script qui lit le code, et si le code et le nombre venaient à diverger, c'est le nombre qui bougerait, pas le code.

Un contrôle ne compte que lorsqu'il se déclenche sur un fichier réel

Chaque contrôle est enregistré avec la voie qui le prouve. La plupart sont prouvés en faisant passer un fichier réel par l'ensemble du pipeline et en voyant le résultat sortir à l'autre bout ; quelques-uns exigent une entrée construite qu'une seule cellule ne peut pas porter, une archive malformée, une réponse réseau ou un appel de modèle. Cette distinction est appliquée, elle n'est pas décorative. Prouver qu'une fonction marche en l'appelant directement dit que la fonction marche ; cela ne dit rien sur le fait que le produit l'atteigne un jour. La suite refuse d'accepter ce type de preuve pour un contrôle qui prétend sortir d'une analyse réelle.

Le même registre attrape les deux défaillances qui laissent s'accumuler des contrôles morts : un code que la source peut émettre et que personne n'a enregistré, et un code enregistré que la source n'émet plus. L'un comme l'autre fait échouer la suite. Deux contrôles sont marqués comme délibérément inatteignables, conservés comme garde-fous contre un mauvais upload qui ferait planter l'analyse, et chacun porte une justification écrite de sa présence. Rien n'est autorisé à rester dans l'état "ne peut pas se déclencher" avec un simple haussement d'épaules.

Ce que le chiffre de rappel signifie, et ce qu'il ne signifie pas

Sur les flux synthétiques que nous construisons pour nos tests, le rappel est de 100 pour cent sur trois formats, xlsx, csv et xml, avec zéro faux positif sur un groupe témoin propre. Notre catalogue de démonstration comporte 55 types de défauts distincts, et chacun d'eux est détecté.

Voici la limite honnête de ce chiffre. Les défauts de ces flux sont ceux que nous avons injectés nous-mêmes ; le chiffre mesure donc que l'analyseur attrape ce que nous avons pensé à planter. Il ne mesure pas que l'analyseur attrape tout ce qu'un catalogue réel contient, et le rappel sur des flux marchands réels reste véritablement inconnu tant que des flux marchands réels n'ont pas été analysés. Nous préférons vous le dire plutôt que d'arrondir vers le haut. L'analyse gratuite est le moyen honnête de découvrir ce qu'un fichier réel produit, et c'est en partie pour cela qu'elle est gratuite.

Les faux positifs que nous avons dû corriger

Le plus difficile, pour être utile, est d'avoir raison quand une valeur est techniquement présente mais dépourvue de sens. Une étape de génération sur l'un de nos flux de test a un jour proposé la couleur "Blue" pour un téléviseur, parce que la colonne couleur indiquait Blue sur la majeure partie du catalogue. La valeur figurait bel et bien dans les données du marchand, et elle était pourtant fausse. Ce qui l'a arrêtée : un filtre de pertinence et une vérification de chaque valeur proposée, mot par mot, par rapport à la ligne source, tous deux écrits après avoir vu la défaillance se produire.

Le même travail en a révélé d'autres qui méritent d'être consignés, parce que ce sont des erreurs qui érodent la confiance en silence : un indice d'étiquette énergétique de l'UE qui correspondait à l'intérieur d'un mot composé néerlandais sans aucun rapport, et une réécriture rejetée pour une différence de flexion de deux caractères, correcte en anglais et fausse dans une langue qui forme ses mots en les accolant. Chacune de ces erreurs a désormais son propre test de régression, pour que la même erreur ne puisse pas revenir inaperçue.

Rien de tout cela ne prétend que le travail est terminé. Cela affirme que les contrôles qui existent peuvent être montrés en train de se déclencher, que le compte est honnête, et que nous sommes clairs sur la différence entre testé et prouvé sur le terrain. Voyez ce qu'un fichier ne peut pas nous dire pour l'autre moitié de cette honnêteté.