End-to-End-Prüfungen

Diese Prüfungen nutzen die öffentliche API, gebaute Befehle, echte lokale Server und kurzlebige PostgreSQL-Datenbanken. Eine End-to-End-Prüfung folgt einer Aufgabe durch diese Teile und prüft das Ergebnis. Einige externe Dienste nutzen feste Testantworten. Die Cloudflare-Prüfung nutzt einen echten Model-Dienst.

Die Projektprüfungen ausführen

Führe die Befehle im Stammverzeichnis des Projekts aus. Der Build muss fertig sein, bevor die Tests starten. Starte keinen Build in einer anderen Shell, während Tests laufen. Ein Build ersetzt dist-Dateien, die Tests und Kindprozesse laden.

devenv shell -- pnpm build
devenv shell -- pnpm typecheck
devenv shell -- pnpm test:e2e
devenv shell -- pnpm -r test

Die Dateien laufen standardmäßig in höchstens vier getrennten Testprozessen. Es laufen nicht mehr Prozesse als CPUs verfügbar sind. Dienste und Datenbanken bleiben getrennt. Tests in einer Datei laufen der Reihe nach. Nutze beim Debuggen --maxWorkers=1 für einen Prozess.

Alle End-to-End-Prüfungen liegen in packages/e2e. Der Paketname ist @openbot-build/e2e. Der Befehl pnpm test:e2e im Stammverzeichnis führt die Typprüfung und die Tests dieses Pakets aus. Führe nach einem Build mit diesem Befehl eine Aufgabengruppe aus:

devenv shell -- pnpm --filter @openbot-build/e2e exec vitest run test/read-docs

Nach einem Build kannst du für eine kleine Änderung eine Datei ausführen oder ihre Änderungen überwachen:

devenv shell -- pnpm --filter @openbot-build/e2e exec vitest run test/chat/ChatQueries.test.ts
devenv shell -- pnpm --filter @openbot-build/e2e exec vitest --watch test/chat/ChatQueries.test.ts

Die Befehle mit exec vitest lassen die Typprüfung des ganzen Pakets bei jedem Lauf aus. Warte zuerst auf das Ende des Builds. Beende den Watch-Modus vor dem nächsten Build. Wenn die Änderung fertig ist, führe pnpm typecheck und pnpm test:e2e aus.

Die Ordner in packages/e2e/test sind nach Benutzeraufgaben benannt. packages/e2e/scenarios.json hält die Prüfungen und Lücken jeder Aufgabe fest. Es trennt normale Fälle, Grenzfälle und Extremfälle. Ein normaler Fall prüft das übliche Ergebnis. Ein Grenzfall prüft eine Eingabe oder einen Zustand nahe der Grenze einer Regel. Ein Extremfall prüft eine große begrenzte Menge, wiederholte Arbeit, Verlust oder Wiederherstellung. Diese Namen bedeuten nicht, dass alle möglichen Eingaben oder Fehler geprüft wurden.

Die Testbefehle der Pakete prüfen auch die Typen der Tests. pnpm test führt alle Testdateien in einem Vitest-Lauf aus. Es baut keine Pakete und prüft keine Testtypen. Pakettests außerhalb von e2e prüfen kleinere Einheiten und Teile des Produkts. Die Tests erstellen und entfernen ihre eigenen lokalen Datenbanken. Sie nutzen keine Produktionsdatenbank.

API-Umfang

packages/e2e/test/api-access/ApiE2E.test.ts liest den HTTP-Vertrag und sendet echte Anfragen an seine geschützten Routen. Es prüft jede geschützte Route ohne Anmeldung. Für jeden geschützten Schreibzugriff prüft es ein Session-Cookie mit einem fehlenden und einem falschen Origin. Das ist eine Zugriffsprüfung. Sie belegt nicht, dass jede Route jede gültige Aufgabe erfüllt. Die Zahl der Routen und Anfragen stammt aus dem aktuellen Vertrag. Der JSON-Bericht hält die genaue Zahl für jeden Lauf fest. Öffentliche Routen und Hook-Routen stehen in einer festen Liste. So sinkt die Abdeckung nicht unbemerkt, wenn eine Regel zur Anmeldung aus Versehen entfernt wird.

Das End-to-End-Paket ordnet die Prüfungen nach Benutzeraufgaben:

Aufgabengruppe	Ordner in packages/e2e/test
Anmelden und den Server starten	sign-in, start-server
Organisationseinstellungen lesen und ändern	organizations, admin-settings
Chatten, Tool-Aufrufe erlauben und Arbeit fortsetzen	chat, approve-tool-calls, chat-recovery
Bots nutzen und freigeben	bot-work
Apps verbinden und einen Protokolldienst nutzen	connect-apps, protocol-service
Dateien lesen und schreiben	files
Kanäle verbinden und Auslöser einstellen	connect-channels, triggers
Code ausführen und Computer verbinden	run-code, connect-computers
Live-Sessions und Model-Dienste nutzen	live-chat, use-models
Befehle ausführen und die Dokumentation lesen	cli, read-docs

Die Dokumentationsprüfungen stellen die gebaute Website auf einem lokalen HTTP-Port bereit. Sie prüfen drei Sprachen des Handbuchs, die API-Referenz, Suchdateien, das Symbol, jede gebaute Datei, lokale Links und dekodierte Anker. API-Seiten haben nur englische Sprachlinks. Externe Links werden nicht abgerufen. Das sind Prüfungen der statischen Website. Sie starten keinen Browser und prüfen weder die interaktive Suche noch Menüs.

Die CLI-Prüfungen starten gebaute Befehle. Die Computer-Prüfungen nutzen auch ein echtes Terminal. Protokollprüfungen nutzen unabhängige Clients und lokale Server. Einheiten- und Komponentenprüfungen bleiben in den Paketen core, domain, api, client, openbot, cli, computer, protocol und protocol-test.

Prüfung mit einem echten Model

Die Prüfung mit einem echten Model läuft nur mit OPENBOT_E2E_LIVE=true. Der normale Lauf überspringt sie. Sie braucht ein Cloudflare-Konto und ein API-Token mit Zugriff auf Workers AI. Wenn das kostenlose Kontingent des Kontos aufgebraucht ist, kosten die Aufrufe Geld. Halte Zugangsdaten außerhalb der Versionsverwaltung.

Der Test erstellt eine Session mit Server.layerFixed. Dann startet er den gebauten Produktionseinstieg, um das echte Model aufzurufen. Die Einrichtung der Session darf keine Index-Arbeit oder Fehler zurücklassen. Der Test prüft Aufrufe mit Cookie und API-Token, gestreamte Antworten, gespeicherte Verläufe, wiederholte Befehle, Verbrauch und den Widerruf von Tokens. Diese kleinen Aufgaben erlauben keine Aussage über die Qualität des Models.

Setze diese Variablen in einer lokalen Shell oder einem Secret-Speicher. Lege den Schlüssel nicht in einem Befehlsargument oder einer versionierten Datei ab.

Variable	Wert
OPENBOT_E2E_LIVE	true, um die Prüfung des echten Dienstes zu starten
OPENBOT_E2E_CLOUDFLARE_ENDPOINT	Die OpenAI-kompatible Basis-URL von Workers AI für das Konto
OPENBOT_E2E_CLOUDFLARE_KEY	Das API-Token
OPENBOT_E2E_CLOUDFLARE_MODEL	Optionale Model-ID; der Standard ist @cf/meta/llama-3.3-70b-instruct-fp8-fast
OPENBOT_E2E_EVIDENCE	Optionaler absoluter Pfad für das Ergebnis als JSON

Führe nach dem Build diesen Befehl aus:

devenv shell -- pnpm --filter @openbot-build/e2e exec vitest run test/use-models/Cloudflare.test.ts

Ohne OPENBOT_E2E_LIVE=true wird dieser Test übersprungen. Ein übersprungener Test des echten Dienstes ist keine erfolgreiche Dienstprüfung.

Paper-Experimente

devenv shell -- python3 papers/experiments/run.py --seeds 30 --output .cache/e2e/papers.json

Der Runner nutzt nur die Python-Standardbibliothek. Er führt die kleinen abstrakten Modelle und die ausgearbeiteten Beispiele aller 15 Papers aus. Das JSON-Ergebnis enthält Eingaben, Seeds, Quellcode-Hashes, Prüfungen, Beobachtungen und Grenzen. Bei einer fehlgeschlagenen Prüfung ist der Exit-Code ungleich null. Eine Prüfung ist eine Zusicherung während eines Laufs. Sie ist keine unabhängige Studie und kein eigener Nutzungsfall.

Die Experimente vergleichen die genannte Methode mit einer Basis, wenn das Paper eine angibt. Sie enthalten Gegenbeispiele: Eingaben, bei denen die Basis eine beabsichtigte Regel verletzt. Bestehen diese kleinen Modelle, belegt das weder die Umsetzung der Methode im Produkt noch das gleiche Ergebnis bei einem großen Dienst.

Paper	Wichtigstes Experiment
01: Dauerhafte Ausführung	Unbekannte externe Ergebnisse, Eigentumsgrenzen und Wiederholung
02: Erhalt von Befugnissen	Aktuelle Rechte, gespeicherte Identität und Zulassung von Aktionen
03: Gestufte Autorisierung	Genaue Regeln, Model-Schwellen und menschliche Prüfung
04: Koordination von Agenten	Unterwegs befindliche Nachrichten, Arbeitszähler und Abschluss einer Aufgabe
05: Gedächtnis mit Belegen	Belege aus zitierten Quellen, Korrekturen und Cursor-Bewegung
06: Informationsfluss im Gedächtnis	Leser der Quellen und Zugriff auf verbundenes Gedächtnis
07: Kontextkürzung	Verbindungen über einen Schnitt hinweg und veraltete Schreibzugriffe
08: Wiederholung von Tool-Programmen	Eingaberahmen, Aufrufreihenfolge, Zustellreihenfolge und Rückgabeprüfungen
09: Secret-Verweise	Secret-Handles, erlaubte Nutzung und Ausgabeformen
10: Tool-Suche	Widersprüchliche Belege und Rückzug bei fehlgeschlagenem Lesen
11: Protokolltests	Erreichbare Zustände und Fehler in erzeugten Ablaufspuren
12: Budgetplanung	Unbekannte Kosten, späte Belege, Preise, Obergrenzen und Anteile
13: Live-Verlauf	Wiedergabebelege, Epochen und festgeschriebene Präfixe
14: Passende Rechenleistung	Ressourcenbedarf und Effektgrenzen für jedes Präfix einer Ablaufspur
15: Zusammensetzung der Laufzeit	Plugin-Reihenfolge, Schutzprüfungen, Hooks und Freigabe von Ressourcen

Unterschiede zwischen Produkt und Papers

Die Papers legen Methoden und Studien fest. Einige Methoden gehen über das aktuelle Produktverhalten hinaus. Halte drei Ergebnisse auseinander: Regressionstests des Produkts, Experimente mit abstrakten Modellen und Prüfungen, die das Produkt mit einer beabsichtigten Regel aus einem Paper vergleichen.

Führe nach dem Build die internen Produktprüfungen für Papers 06 und 12 aus:

devenv shell -- node --disable-warning=ExperimentalWarning packages/openbot/test/PaperProductEvidenceMain.ts --strict

Diese Prüfungen rufen interne Dienste auf. Sie vergleichen Produktregeln mit den Papers. Sie sind keine End-to-End-Benutzeraufgaben in packages/e2e.

Der Befehl schreibt seine Belege als JSON in die Standardausgabe. Mit --strict ist der Exit-Code ungleich null, wenn eine beabsichtigte Paper-Regel verletzt wird. Die Prüfungen stellen zuerst sicher, dass die Testdaten und Zugriffsregeln vorliegen. Fehlende Daten können eine Prüfung nicht bestehen lassen.

Die Prüfung für Paper 06 verbindet Quellen von Ana und Bob zu einem Gedächtniseintrag. Ein früher Lauf zeigte, dass beide das Ergebnis ohne Zugriff auf die Quelle der anderen Person lesen konnten. Die Prüfung verlangt jetzt Zugriff auf jede Quelle. Keine der beiden Personen darf das Ergebnis allein lesen. Eine Gruppe, die beide Quellen lesen darf, darf es lesen. Andere Benutzer und Organisationen bleiben gesperrt. Das ist die Schnittmenge der Quellenleser: Nur Leser, die alle Quellen gemeinsam haben, dürfen das Ergebnis lesen. Altes Memory ohne Nachweis des Zugriffs auf seine Quellen bleibt bis zu einem Neuaufbau verborgen.

Die Prüfung für Paper 12 setzt eine Obergrenze von 1.000 microUSD. Ein microUSD ist ein Millionstel eines US-Dollars. Ein früher Lauf gab den Schätzwert des ersten Aufrufs frei, als dessen Kosten unbekannt wurden. Ein zweiter Aufruf gab den frei gewordenen Betrag aus. Ein später Beleg für den ersten Aufruf hob die Endkosten dann auf 2.000 microUSD. Die Prüfung verlangt jetzt, dass OpenBot die Reservierung behält und den zweiten Aufruf stoppt. Ein bestätigter Beleg ersetzt die Reservierung durch die echten Kosten. Derselbe Beleg darf keine weiteren Kosten auslösen. Ein alter unbekannter Aufruf, dessen Reservierung verloren ging, muss neue Aufrufe unter seinen betroffenen harten Budgets stoppen, bis seine Kosten bestätigt sind. Reservierungen mit unbekannten Kosten müssen auch bei einem neuen Budget-Zeitraum erhalten bleiben.

Diese Prüfungen müssen bestehen, bevor die Reparaturen als abgeschlossen gelten. Sie beweisen keine feste Grenze für die Endkosten des Anbieters. Die Grenze in Paper 12 setzt voraus, dass jeder reservierte Betrag eine geprüfte Obergrenze für die Kosten seines Aufrufs ist. OpenBot nutzt einen Schätzwert aus der Größe der Eingabe und einer festen Menge an Ausgabe-Tokens. Die echten Kosten können diesen Wert überschreiten. Siehe Budgets.

Die vorhandenen Produkttests belegen weder die Geräte-Wiedergabebelege aus Paper 13 noch die Platzierungsregeln anhand von Ablaufspuren aus Paper 14 oder die strengeren Registrierungsprüfungen aus Paper 15. Beschreibe bestandene Adapter- oder Plugin-Tests nicht als Nachweis dieser Methoden.

Grenzen

Ein vollständiger Testlauf deckt die benannten Eingaben und Pfade ab. Er kann nicht alle möglichen Eingaben, Netzwerkfehler oder Zustände externer Dienste abdecken. Eine erzeugte Zugriffsprüfung deckt nicht alle Aufgaben ihres Endpunkts ab. Ein Lauf mit einem kleinen Modell ist kein Lasttest für die Produktion.

Echte Zustellung über externe Kanäle, SSO-Anbieter, Cloud-Computer-Anbieter, Objektspeicher und Sprachwiedergabe brauchen eigene Dienstkonten und Testressourcen. Feste Testserver prüfen den lokalen Vertrag für diese Pfade. Sie belegen nicht, dass ein echter externer Dienst funktioniert.

Unter Mitwirken findest du die Entwicklungswerkzeuge. Die API-Referenz beschreibt den HTTP-Vertrag.