Leitfaden · Abläufe im Dienstleistungsbetrieb
Wie sich das Beispiel zur Anfrage-Weiterleitung im Test verhält
Sehen Sie sich fünf ausgeführte Fälle zu Aufnahme, Duplikaten und Wiederherstellung an, mit reproduzierbaren Eingaben und klaren Grenzen dessen, was ein Browser-Beispiel belegt.
Von Fireflax · 8 Minuten Lesezeit
Geprüft von Codex — source and implementation review ·
Was hat dieses Beispiel tatsächlich getan?
Wir haben am 8. Oktober 2026 fünf festgelegte Wege im fiktiven Anfrage-Workflow von Northstar Plumbing geprüft. Jeder Weg lief gegen die Anfrageregeln des Repositorys und separat gegen das herunterladbare Starter-Paket. Die Tabelle hält diese begrenzten Ergebnisse fest; sie ist weder eine Kundenfallstudie noch eine Kennzahl zur Zuverlässigkeit im Live-Betrieb.
Testumfang
Fünf Fälle pro Umsetzung, insgesamt zehn Testläufe. Jede Umsetzung verzeichnete fünf bestandene und null fehlgeschlagene Fälle. Die Tests liefen lokal mit Node.js 22.23.2, synthetischen Eingaben und ohne Netzwerk-Konnektor. Sie prüften die Regeln, die die Browser-Demo nutzt; sie bedienten kein Live-Postfach, kein CRM und keinen Nachrichtendienst.
Eingaben und Erwartungen wurden zuerst festgelegt.
Das vollständige Testbeispiel ist Alex Morgan, alex@example.com, Bristol BS1, mit einer Anfrage zu einem Küchenhahn, der seit einer Woche tropft. Das unvollständige Testbeispiel ist Sam Taylor, sam@example.com, ohne Gebiet und mit der Nachricht „Can you help?“. Das sind fiktive Kontakte.
Der Duplikat-Fall reicht Alex’ Anfrage erneut ein, mit anderem Anzeigenamen, Großbuchstaben und zusätzlichen Leerzeichen. Die wiederholte Freigabe versucht, eine bereits freigegebene Antwort zu ersetzen. Der Wiederherstellungsfall nutzt das ausdrückliche Flag für einen simulierten Fehler, versucht die Wiederherstellung zu umgehen, stellt denselben Datensatz wieder her und gibt ihn dann erneut frei.
| Weg | Erwartet | Beobachtet |
|---|---|---|
| Vollständige Anfrage | Eine „Plumbing enquiry“ für den „Service coordinator“; vor dem Abschluss ist eine Freigabe nötig. | Beide Läufe: Prüfung → abgeschlossen; ein Datensatz; geprüfter Text erhalten. |
| Fehlende Angaben | Nach Gebiet und Auftragsdetails fragen; die Freigabe darf die fehlenden Angaben nicht als erledigt markieren. | Beide Läufe: Prüfung → wartet auf Angaben; beide fehlenden Punkte erhalten. |
| Normalisiertes Duplikat | Gleiche E-Mail, gleiches Gebiet und gleiche Nachricht mit anderer Schreibweise/Leerzeichen liefert den bestehenden Datensatz. | Beide Läufe: gleiche ID und ein Datensatz; Status/Verlauf unverändert. Ein geänderter Anzeigename änderte die Übereinstimmung nicht. |
| Wiederholte Freigabe | Eine zweite Freigabe darf die abgeschlossene Antwort nicht ersetzen und keinen Verlauf hinzufügen. | Beide Läufe: abgeschlossener Status und ursprünglich freigegebener Text unverändert. |
| Fehler und Wiederherstellung | Blockierten Datensatz und Entwurf behalten; direkte erneute Freigabe verhindern; Wiederherstellung erfordert eine neue Freigabe. | Beide Läufe: blockiert → Prüfung mit gelöschter vorheriger Freigabe → abgeschlossen; durchgehend ein Datensatz. |
Vollständige Anfrage
Erwartet: Eine „Plumbing enquiry“ für den „Service coordinator“; vor dem Abschluss ist eine Freigabe nötig.
Beobachtet: Beide Läufe: Prüfung → abgeschlossen; ein Datensatz; geprüfter Text erhalten.
Fehlende Angaben
Erwartet: Nach Gebiet und Auftragsdetails fragen; die Freigabe darf die fehlenden Angaben nicht als erledigt markieren.
Beobachtet: Beide Läufe: Prüfung → wartet auf Angaben; beide fehlenden Punkte erhalten.
Normalisiertes Duplikat
Erwartet: Gleiche E-Mail, gleiches Gebiet und gleiche Nachricht mit anderer Schreibweise/Leerzeichen liefert den bestehenden Datensatz.
Beobachtet: Beide Läufe: gleiche ID und ein Datensatz; Status/Verlauf unverändert. Ein geänderter Anzeigename änderte die Übereinstimmung nicht.
Wiederholte Freigabe
Erwartet: Eine zweite Freigabe darf die abgeschlossene Antwort nicht ersetzen und keinen Verlauf hinzufügen.
Beobachtet: Beide Läufe: abgeschlossener Status und ursprünglich freigegebener Text unverändert.
Fehler und Wiederherstellung
Erwartet: Blockierten Datensatz und Entwurf behalten; direkte erneute Freigabe verhindern; Wiederherstellung erfordert eine neue Freigabe.
Beobachtet: Beide Läufe: blockiert → Prüfung mit gelöschter vorheriger Freigabe → abgeschlossen; durchgehend ein Datensatz.
Führen Sie es aus und vergleichen Sie Ihr eigenes Ergebnis.
Laden Sie Starter 1.0.0 herunter, entpacken Sie ihn und folgen Sie seiner README. Die enthaltenen Prüfungen enthalten die erwarteten Zustände und Zusicherungen. Führen Sie node verify.mjs aus, um einen neuen Bericht mit Eingaben, Erwartungen und beobachtetem Verlauf für alle fünf Fälle zu erzeugen. Schlägt ein Fall fehl, endet der Befehl mit einem Fehler.
Der Lauf gegen den Repository-Quellcode rief die aktuellen TypeScript-Hilfsfunktionen direkt auf. Der Starter-Lauf lud das gebündelte JavaScript, ohne Repository-Dateien zu importieren. Ihre gemeinsamen Testdefinitionen machen den Vergleich reproduzierbar; die beiden Läufe sind kein unabhängiger Beweis dafür, dass jede mögliche Regel korrekt ist.
Das Paket hat außerdem eine separate Pausen-Probe.
Der Kommandozeilen-Wrapper des Pakets ergänzt lokale Dateispeicherung und Steuerung für Pause/Fortsetzen. Seine Probe aus elf Befehlen initialisierte einen Datensatz, simulierte einen Fehler, pausierte, versuchte eine blockierte Wiederherstellung, setzte fort, stellte wieder her, gab zweimal frei und setzte zurück. Die Wiederherstellung im pausierten Zustand endete absichtlich mit einem Fehler und ließ den Zustand unverändert. Das Fortsetzen hat keine Aktion wiederholt.
Das ist eine erfolgreiche Negativprüfung, kein verschwiegener fehlgeschlagener Test. node cli-check.mjs führt die Abfolge in einem temporären Ordner aus und entfernt diesen Ordner danach. Diese CLI-Funktionen gibt es in der Browser-Demo nicht.
Was unbewiesen bleibt
Der Duplikatspeicher des Browsers verschwindet beim Zurücksetzen, Neuladen oder Workflow-Wechsel. Der Starter speichert eine lokale Datei, hat aber keine Sperre für mehrere Nutzer und keinen Datenspeicher für den Live-Betrieb. Eine geänderte Nachricht kann eine neue Anfrage sein; dieser Schlüssel kann nicht entscheiden, ob zwei unterschiedlich formulierte Anfragen denselben Auftrag beschreiben.
Eine echte Umsetzung bräuchte dauerhafte Kennungen für Anfragen und Aktionen, eine Entscheidung zu geänderten Anfragen und eine Prüfung des Ziels vor einem neuen Versuch. Das sind notwendige Ergänzungen, keine Lösungen, die diese lokalen Ergebnisse belegen. Der simulierte Fehler sendet nichts und testet daher keine Verbindung, die erfolgreich gehandelt und danach ihre Bestätigung verloren hat.
Aus diesen fünf Fällen folgen keine Arbeitszeitersparnisse bei Kunden, keine Abschlussquote, keine Live-Integration, keine Verfügbarkeit und keine Genau-einmal-Zustellung. Die bestehende Unit-Test-Suite des Repositorys hat separat 21 Prüfungen der Anfrage-Hilfsfunktion bestanden. Diese breitere Suite ist eine nützliche Regressionsabdeckung, keine 21 Kundentests und keine 21 Browser-Sitzungen.
Quellen und Prüfhinweise
Mit Codex entworfen und anhand ausgeführter fiktiver Beispieltests, des Quellcodes und einer unabhängigen Starter-Probe durch Codex geprüft. Diese Ergebnisse belegen weder eine Live-Integration noch ein Kundenergebnis.
- Aufbewahrter Test der Browser-Hilfsfunktionen
Eingaben, Erwartungen und beobachtete Zustände aus der tatsächlichen Ausführung des Quellcodes.
- Anfragebeispiel testen
Prüf- und Fehlerwege mit fiktiven Angaben nachstellen.