FeedMender

FeedMender/Woher wir es wissen

Belege

Wie die Prüfungen belegt werden

Eine Prüfung, die geschrieben, dokumentiert und berechnet wurde, aber nie tatsächlich anschlägt: Das ist der Defekt, in dessen Ausmerzung dieses Projekt die meiste Arbeit gesteckt hat. Deshalb muss jede Prüfung zeigen, dass sie bei einer echten Datei anschlagen kann, bevor sie zählen darf, und die Zahl selbst wird aus dem Code gelesen statt eingetippt.

Die Zahl ist nicht eingetippt

Es gibt 225 verschiedene Prüfungen. Diese Zahl steht nicht fest in dieser Seite: Sie wird beim Build aus dem Quellcode gelesen, aus derselben Registry, an der sich auch die Testsuite misst. Eine von Hand eingetippte Zahl ist eine Behauptung, die niemand nachprüft, und jedes interne Audit dieses Projekts fand eine, die veraltet war. Die Zahl auf der vollständigen Liste der Prüfungen wird deshalb von einem Skript erzeugt, das den Code liest, und sollten Code und Zahl je auseinanderlaufen, würde sich die Zahl bewegen, nicht der Code.

Eine Prüfung zählt erst, wenn sie bei einer echten Datei anschlägt

Jede Prüfung ist mit dem Weg registriert, der sie belegt. Die meisten werden belegt, indem eine echte Datei den ganzen Weg durch die Pipeline nimmt und das Ergebnis am anderen Ende herauskommt; einige wenige brauchen eine konstruierte Eingabe, die eine einzelne Zelle nicht tragen kann, ein beschädigtes Archiv, eine Netzwerkantwort oder einen Modellaufruf. Diese Unterscheidung wird erzwungen, sie ist keine Dekoration. Wer eine Funktion direkt aufruft und zeigt, dass sie funktioniert, zeigt nur, dass die Funktion funktioniert. Ob das Produkt sie je erreicht, sagt das nicht. Für eine Prüfung, die aus einem echten Scan kommen soll, akzeptiert die Suite diese Art von Beleg nicht.

Dieselbe Registry fängt die beiden Fehler ab, durch die sich tote Prüfungen ansammeln: ein Code, den der Quellcode ausgeben kann, den aber niemand registriert hat, und ein registrierter Code, den der Quellcode nicht mehr ausgibt. Beides lässt die Suite fehlschlagen. Zwei Prüfungen sind als bewusst unerreichbar markiert; sie bleiben als Schutz dagegen, dass ein fehlerhafter Upload den Scan zum Absturz bringt, und jede trägt eine schriftliche Begründung für ihre Existenz. Nichts darf achselzuckend im Zustand „kann nicht anschlagen“ stehen bleiben.

Was die Recall-Zahl bedeutet, und was nicht

Auf den synthetischen Feeds, die wir zum Testen bauen, liegt der Recall bei 100 Prozent über drei Formate (xlsx, csv und xml), mit null False Positives auf einer sauberen Kontrollgruppe. Unser Demonstrationskatalog enthält 55 verschiedene Defekttypen, und jeder einzelne wird erkannt.

Und hier die ehrliche Grenze daran: Die Defekte in diesen Feeds haben wir selbst eingebaut. Die Zahl misst also, dass der Scanner findet, was wir zu verstecken wussten. Sie misst nicht, dass der Scanner alles findet, was ein echter Katalog enthält, und der Recall auf echten Händler-Feeds ist schlicht unbekannt, bis echte Händler-Feeds gescannt werden. Wir sagen Ihnen das lieber, als die Zahl aufzurunden. Der kostenlose Scan ist der ehrliche Weg herauszufinden, was eine echte Datei ergibt, und das ist mit ein Grund, warum er kostenlos ist.

Die False Positives, die wir beheben mussten

Der schwierigste Teil des Nützlichseins ist, richtig zu liegen, wenn ein Wert technisch vorhanden, aber bedeutungslos ist. Ein Generierungsschritt auf einem unserer Test-Feeds schlug einmal die Farbe „Blue“ für einen Fernseher vor, weil die Farbspalte im Großteil des Katalogs Blue enthielt. Der Wert stand tatsächlich in den Daten des Händlers, und er war trotzdem falsch. Gestoppt haben ihn ein Relevanzfilter und eine Wort-für-Wort-Prüfung jedes vorgeschlagenen Werts gegen die Quellzeile, beide geschrieben, nachdem wir dem Fehler zugesehen hatten.

Dieselbe Arbeit brachte weitere Fälle ans Licht, die es wert sind, festgehalten zu werden, weil sie zu der Sorte Fehler gehören, die Vertrauen leise untergräbt: ein Hinweis auf ein EU-Energielabel, der mitten in einem gänzlich anderen niederländischen Kompositum ansprang, und eine Umschreibung, die wegen eines Flexionsunterschieds von zwei Zeichen abgelehnt wurde, der für Englisch richtig ist und falsch für eine Sprache, die Wörter durch Zusammensetzen bildet. Jeder dieser Fälle hat inzwischen einen eigenen Regressionstest, damit derselbe Fehler nicht unbemerkt zurückkehren kann.

Nichts davon ist die Behauptung, fertig zu sein. Es ist die Behauptung, dass sich für die vorhandenen Prüfungen zeigen lässt, dass sie anschlagen, dass die Zahl ehrlich ist und dass wir den Unterschied zwischen getestet und in der Praxis belegt klar benennen. Die andere Hälfte dieser Ehrlichkeit steht unter Was eine Datei uns nicht sagen kann.