Fanout-Parser testen: ein ausführbares Offline-Kit mit Fehlerfällen

Entpacke das Kit, installiere die gelockten Abhängigkeiten mit npm ci und starte npm test. Die 16 Parser- und elf Exportprüfungen verwenden eigene synthetische Fixtures. Negative Tests müssen falsche Eingaben ablehnen, nicht bloß gültige Beispiele akzeptieren.

Vor einer Parser-Änderung oder bei einem unklaren Importfehler. Nach der Paketinstallation arbeitet das Kit ohne Netzwerk und ohne Provider-Schlüssel.

Prüfe anschließend ein eigenes ErgebnisDas Offline-Kit braucht keinen API-Schlüssel. Im kostenlosen Tool kannst du später einen separaten, begrenzten Lauf prüfen.Kostenloses Tool öffnen

Eine unabhängige Kopie ausführen

Prüfe die Anleitung mit dem Download, nicht nur in einem Entwicklungscheckout mit bereits vorhandenen Abhängigkeiten. Entpacke das ZIP in einen neuen Ordner. Im Ordner fanout-kit-v2 findest du README, Parser, Tests, Schema, Validator, Fixtures und ein Lockfile. Die Installation braucht Zugriff auf die Paket-Registry; danach bleiben die Prüfläufe offline.

npm test startet den eingebauten Node-Testläufer. Im geprüften Kit bestehen 27 Fälle. npm run validate prüft anschließend die vier Exportfamilien separat. Die Zahl beschreibt die enthaltenen Prüfungen, keine Garantie vollständiger Fehlerabdeckung. Eine fehlende Datei oder ein nicht installiertes Ajv ist ein Setup-Problem, kein Provider-Ergebnis.

Vertiefe das mit die geprüften Verträge verstehen.

Das Kit wurde mit Node.js 24.15.0 ausgeführt. Es fragt keine API ab und erwartet keine Umgebungsvariable mit einem Schlüssel. Die erfundenen Domain-, Modell- und Usage-Angaben sind als synthetisch gekennzeichnet. Bewahre private eigene Antworten außerhalb der öffentlichen Dateien auf, wenn du zusätzliche Tests ergänzt.

Im entpackten Ordner ausführen

npm ci --ignore-scripts
npm test
npm run validate

Jede Fehlerklasse braucht ein anderes Soll-Ergebnis

Ein erfolgreicher Leerfall erwartet exposedQueryCount 0. Ein unvollständiger Lauf ohne sichtbare Strings erwartet null und state partial. Eine Fehlerantwort erwartet failed. Fehlt der Status, bleibt er unknown. Ein ungültiges output- oder steps-Feld muss werfen. Würde jeder Fall [] zurückgeben, gingen die entscheidenden Unterschiede verloren.

Andere Tests prüfen Datenverlust und erfundene Beziehungen. Großschreibung, zerlegte Unicode-Zeichen, Leerzeichen und Duplikate bleiben exakt. Mehrere Aktionen behalten ihre Query-Gruppen. URL-Annotationen gehen nicht in eine willkürliche Query-Zeile. Credential-URLs werden verworfen. Ein synthetischer Marker aus google_search_result darf nie im Ergebnis stehen.

Bei Exporten müssen falsche Zählwerte, doppelte Indizes, erfundene Quellenfelder und eine falsche Version fehlschlagen. Das ist eine andere Aufgabe als Rohantworten zu parsen. Du kannst daher einen erfolgreichen Parser-Test und zugleich einen fehlgeschlagenen Export-Test haben; prüfe zuerst die betroffene Schicht.

Vertiefe das mit den Interactions-Parser prüfen.

Soll-Zustände unterscheiden

Vertrag des Offline-Lehr-Parsers. Nicht jede Regel ist identisch mit der Website-Normalisierung.

Eingabe	Soll	Verhindert
completed + []	completed · 0	Erfundene Queries
incomplete + []	partial · null	Falscher erfolgreicher Leerfall
failed + error	failed · null	Fehler als Beobachtung
output: {}	INVALID_RESPONSE	Schemafehler als Leerfall

Einen neuen Randfall reproduzierbar ergänzen

Schreibe zuerst eine kleine eigene Eingabe und das erwartete Ergebnis. Der kurze Test unten ergänzt einen HTTP-unabhängigen Schemafehler. Speichere ihn im Kit-Ordner als extra.test.mjs und starte node --test extra.test.mjs. Er besteht nur, wenn der Parser die falsche Liste tatsächlich ablehnt.

Wenn der Test fehlschlägt, entscheide anhand des dokumentierten Vertrages, ob Implementierung oder Erwartung falsch ist. Ersetze einen Fehlfall nicht durch ein gültiges Beispiel, nur um grün zu erhalten. Bei einer Provider-Änderung notierst du Feldpfad, Prüfdatum und betroffene Parser-Version im eigenen Änderungsprotokoll.

Vertiefe das mit die Extraktionsentscheidungen prüfen.

Transport-Timeouts, echte Provider-Erreichbarkeit, Berechtigungen und die rechtskonforme Speicherung deiner Anwendung sind zusätzliche Prüfaufgaben. Das Offline-Kit behauptet dafür keinen Nachweis. Ebenso ist eine grüne Testausgabe kein Nachweis besserer Rankings. Ihr Nutzen ist ein reproduzierbarer Datenvertrag für die nächste Implementierungsentscheidung.

Eigener negativer Test

import test from "node:test";
import assert from "node:assert/strict";
import { parseOpenAiResponse } from "./parsers.mjs";
test("reject malformed output", () => {
  assert.throws(() => parseOpenAiResponse({
    status: "completed", output: {}
  }), /INVALID_RESPONSE/);
});

Verwendete Quellen

Diese Quellen stützen die beschriebenen Funktionen und Grenzen. Sie belegen keine darüber hinausgehenden Aussagen.

Eigenes ausführbares Offline-Parser- und Randfall-Testkit
Eigener Lehrcode und 27 Offline-Prüfungen. Synthetische Antwortstrukturen sind keine Provider-Ausgaben. Geprüft werden Strings, Status, Quellenumfang und ausgeschlossene Payloads. Kein bezahlter Aufruf oder neues reales Grounding-Material; der Lehr-Parser unterscheidet sich ausdrücklich vom Website-Wrapper.
Quelle öffnen
Aktuelle Website-Exportverträge und Referenzvalidierung
Draft-2020-12-Referenz für aktuelle native/modellierte Vollruns, Query-Auswahlen und lokale Vergleiche. Geprüft gegen tatsächliche Service-/Exportfunktionen mit synthetischen Provider-Stubs und negativen Semantiktests. Vollruns erhalten keine erfundene root-schemaVersion; ältere Planner- und Handoff-Formate bleiben getrennt.
Quelle öffnen