TesterArmy e2e: KI-Testschritte, klare Assertions und Replay in der Praxis

Was ist TesterArmy e2e?

Ein End-to-End-Test prüft einen Ablauf aus Nutzersicht: Seite öffnen, etwas eingeben oder anklicken und das erwartete Ergebnis kontrollieren. TesterArmy nennt sein Open-Source-Testframework schlicht e2e. Es ist ein eigener Runner mit SDK und CLI, nicht mit der gehosteten TesterArmy-Plattform gleichzusetzen.

Der interessante Ansatz ist die Mischung: Stabile Schritte bleiben konkrete Locator-Aktionen. Einen variablen Teil kannst du als Ziel an agent.act übergeben. Danach prüfst du das Ergebnis möglichst mit einer genauen Assertion. Das Web-Paket verwendet Playwright, das Mobile-Paket agent-device. Die Migrationsanleitung sieht ausdrücklich einen Parallelbetrieb mit bestehenden Playwright-Tests vor.

Kerndatum	Stand der Recherche	Beleg
Lizenz	Apache-2.0	LICENSE am Release-Commit
Hauptsprache	TypeScript	Repository
Runner und CLI	e2e@0.20.0	npm-Paketmanifest
Web-Engine	@e2e-dev/web@0.14.0, mit playwright-core@1.63.0	npm-Paketmanifest
Mobile-Engine	@e2e-dev/mobile@0.12.0	npm-Paketmanifest
Geprüftes Release	Tag e2e@0.20.0, veröffentlicht am 12. Oktober 2026	GitHub-Release
Node-Anforderung	Node 22 ab 22.22.3 oder Node ab 24.8.0; unter Windows laut Anleitung WSL	Manifest, Quickstart
GitHub-Aufmerksamkeit	10.263 Stars im Snapshot vom 14. Oktober 2026, 10:14:30 CEST	Lokaler GitHub-API-Snapshot vom 14.10.2026, 10:14:30 CEST; GitHub-API

Die exakte Node-Engine-Range des veröffentlichten Pakets lautet:

^22.22.3 || >=24.8.0

Die Zahlen beschreiben einen Snapshot, keine Qualitätsmessung. Die Paketversionen sind außerdem getrennt: Eine neue Mobile-Version bedeutet nicht automatisch eine neue Runner-Version. Für die folgenden Schritte zählt das veröffentlichte Paket, nicht ein späterer main-Commit oder ein Nightly-Build.

Wie startest du ohne KI-Modell?

Beginne mit einem kleinen Test, dessen Ergebnis eindeutig ist. So trennst du Browser-, App- und Runner-Probleme von Modellproblemen. Der Quickstart bestätigt: Tests ohne Agentenschritte brauchen weder Modell-Login noch API-Key.

Pakete installieren und die App vorbereiten

Voraussetzung ist ein bestehendes ESM-Node-/TypeScript-Projekt, dessen package.json "type": "module" enthält. Starte deinen Entwicklungsserver auf http://localhost:3000 oder ändere die URL in der Konfiguration. Die gepinnten Pakete stammen aus den oben verlinkten npm-Manifesten:

npm install -D e2e@0.20.0 @e2e-dev/web@0.14.0

Lege im Projektroot e2e.config.ts an. Die folgenden Grenzen sind bewusst gewählte Pilotwerte, keine Leistungsbehauptung:

import type { E2EConfig } from 'e2e';
import { web } from '@e2e-dev/web';

export default {
  workers: 1,
  retries: 0,
  timeout: 30_000,
  targets: [{
    name: 'web',
    engine: web(),
    app: { url: 'http://localhost:3000' },
  }],
} satisfies E2EConfig;

Hier startet e2e nicht deinen App-Server. Der muss bereits laufen. Alternativ kannst du den dokumentierten app.command-Weg verwenden. Eine fehlende Browserinstallation lädt der Runner laut Quickstart beim Lauf nach; dieser automatische Download wurde in unserer eigenen Prüfung nicht getestet.

Einen konkreten Ergebnisvertrag testen

Das Beispiel setzt eine Demo-App mit einem Button namens Increment und einer Anzeige mit role="status" voraus. Nach einem Klick muss deren Text exakt Count: 1 lauten. Auf einer beliebigen Website ohne diese Controls funktioniert der Test nicht.

Speichere ihn als tests/counter.e2e.ts:

import { test } from '@e2e-dev/web';
import { expect } from 'e2e';

test('counter increments', async ({ app, screen }) => {
  await app.open('/');
  await screen.getByRole('button', 'Increment').click();
  await expect(screen.getByRole('status')).toHaveText('Count: 1');
});

Erst die Erkennung, dann die Ausführung prüfen:

E2E_TELEMETRY_DISABLED=1 npx e2e list
E2E_TELEMETRY_DISABLED=1 npx e2e run --workers 1 --retries 0

Die Standarddateisuche ist tests/**/*.e2e.ts. Wichtig für Umsteiger: e2e behandelt Strings in den semantischen Namensabfragen standardmäßig exakt und case-sensitive. Save trifft damit nicht automatisch Save changes. Die Playwright-Migrationsreferenz beschreibt diese Unterschiede sowie die Optionen für Teilstrings.

Wann ist der Setup-Assistent sinnvoll?

Wenn du lieber geführt einrichtest, starte npx e2e@0.20.0 init interaktiv und wähle Web sowie None für den Modellpfad. Prüfe die angebotenen Änderungen an deinem Projekt.

init --yes ist kein neutraler modellfreier Schnellstart. Im veröffentlichten Quickstart ist dokumentiert, dass dieser Weg eine Web-Konfiguration mit Vercel AI Gateway sowie Skill-/MCP-Dateien schreibt, aber zunächst keine Dependencies installiert. Ein späterer Agentenschritt braucht dann die passende Providerkonfiguration.

Wann ergänzt ein Agentenschritt deinen Test?

Wenn ein stabiler Button direkt adressierbar ist, bringt eine Modellentscheidung für denselben Klick wenig. Interessanter sind begrenzte Abläufe mit wechselnder Anordnung oder mehreren möglichen Bedienwegen, etwa ein Einrichtungsdialog. Das fachliche Ziel muss trotzdem unverändert bleiben.

Baustein	Aufgabe	Sinnvolle Verwendung
screen.getByRole(...).click()	Ein bestimmtes Control bedienen	Stabile Navigation und klar benannte Aktionen
expect(locator).toHaveText(...)	Einen konkreten Inhalt prüfen	Mengen, Status, Auswahl und andere eindeutige Ergebnisse
agent.act(...)	Ein abgegrenztes Ziel erreichen	Variable Strecke zwischen klaren Start- und Endbedingungen
agent.assert(...)	Den Bildschirm semantisch beurteilen	Offene Inhalte, bei denen genaue Strings nicht ausreichen
agent.waitFor(...) / agent.extract(...)	Semantisch warten oder Daten gewinnen	Modellgestützte Beobachtung, nicht automatisch ein harter Ergebnisvertrag

Die Quickstart- und Cache-Dokumentation unterscheidet Aktionen und Folgeprüfungen ausdrücklich. Ein Modellurteil ist dabei keine deterministische Assertion. Für Beträge, Berechtigungen oder Stückzahlen würde ich eine konkrete Prüfung vorziehen.

Ein Ziel, danach eine eindeutige Prüfung

Nach Einrichtung eines Modells könnte tests/cart.e2e.ts so aussehen:

import { test } from '@e2e-dev/web';
import { expect } from 'e2e';

test('adds one item to the cart', async ({ app, agent, screen }) => {
  await app.open('/cart');
  await agent.act('add one item to the cart');
  await expect(screen.getByRole('status')).toHaveText('1 item');
});

Das ist ein an die offizielle Cache-Anleitung angelehntes Beispiel, kein auf unserem VPS ausgeführter LLM-Test. Es setzt einen leeren Warenkorb, passende Controls und ein konfiguriertes Modell voraus. Die modellfreie Konfiguration aus dem vorherigen Abschnitt reicht dafür nicht.

Die Assertion prüft nur den angezeigten Status. Für einen echten Shop brauchst du gegebenenfalls weitere Kriterien: richtiges Produkt, richtige Menge, Preis und tatsächlich gespeicherter Warenkorb. Ein grünes Label allein beweist keine korrekte Bestellung.

Modell und Anmeldung separat konfigurieren

e2e unterstützt AI-SDK-Provider und einen eigenen ChatGPT/Codex-Adapter über e2e/oauth/chatgpt. Die Subscriptions-Anleitung beschreibt den Login und die Modellauflistung:

E2E_TELEMETRY_DISABLED=1 npx e2e login openai --device
E2E_TELEMETRY_DISABLED=1 npx e2e models openai

Führe das nur aus, wenn du deinen Account bewusst mit dem Framework verbinden willst. Anschließend muss die Modellkonfiguration entsprechend der Providerdokumentation in agents.default ergänzt werden. Ein bestehender Hermes-Login wird dadurch nicht automatisch übernommen.

In unserer Prüfung wurde weder dieser Login gestartet noch ein Token kopiert. Ob das gewünschte Modell gpt-6.1-sol über den Frameworkadapter verfügbar ist, blieb unbestätigt. Deshalb gibt es hier kein als getestet ausgegebenes Modell-Configliteral. Runner, Modell und Verifikation sind unterschiedliche Ebenen; die Einordnung dazu findest du im AI-Harness-Guide.

Wie funktioniert Replay, und was bedeutet „verified“?

Der Replay-Cache speichert Aktionen eines agent.act-Schritts erst, wenn eine spätere geeignete Prüfung besteht. Beim nächsten Lauf sucht der Runner die aufgezeichneten Controls und führt die Aktionen erneut aus. Passt die Aufnahme nicht mehr, übernimmt normalerweise wieder der Agent.

Entscheidend ist das Wort geeignet. Nicht jede Prüfung zählt für die Cache-Freigabe. Laut Cache-Vertrag zum geprüften Release gilt:

Gibt eine Aufnahme frei	Gibt sie nicht frei
Locator-Assertions wie toHaveText	expect(value).toBe(...) auf einem einfachen Wert
Engine-Assertions wie eine URL-Prüfung	expect.poll(...)
Bestimmte Locator-/Browser-Waits	Bloßes Auslesen von Text
agent.assert oder agent.waitFor	agent.extract, ein weiterer act oder bloßes Bestehen des Tests

Ohne Folgeprüfung kann ein Test grün sein, während der Report unconfirmed meldet und die Aufnahme nicht speichert. Umgekehrt kann auch ein fehlbares Modellurteil die Aufnahme freigeben. „Verified“ bedeutet hier: Eine vom Framework anerkannte Prüfung ist bestanden. Es bedeutet nicht: Die Geschäftslogik wurde bewiesen.

Was wird tatsächlich wiedergefunden?

Der Runner prüft die Startroute, findet Controls anhand von Rolle, Name, Test-ID und Kontext und kontrolliert ausgewählte Endzustandsänderungen. Die Aufnahme enthält Aktionen, Targetbeschreibungen, getippten Text, eine Zusammenfassung und Endzustandsanker. Sie ist keine vollständige Aufzeichnung aller Backend-Zustände.

Ein erfolgreicher Replay ersetzt außerdem keine spätere fachliche Assertion. Beim eingebauten Agenten bleiben agent.assert, agent.waitFor und agent.extract live modellabhängig. Ein eigener StepExecutor kann act und assert auch modellfrei ausführen. agent.waitFor und agent.extract verwenden weiterhin die eingebauten Modellurteile. Unsere Replay-Vertragsprüfung nutzte einen solchen deterministischen Executor für agent.act, keine LLM-Simulation.

Auch ein Modellwechsel erzeugt nicht automatisch einen Cache-Miss. Das dokumentieren die Cache-Anleitung und Issue #1000. Ein grüner Replay bewertet somit nicht die Qualität des gerade neu konfigurierten Modells.

Wie behandelst du den Cache in CI?

Beim lokalen Dateistore ist read-write der Standard. In CI ist der Default bei nicht gesetzter Cachekonfiguration read-only. init nimmt .e2e/cache/ in .gitignore auf. Ohne bewusste Übertragung startet eine frische CI-Umgebung daher ohne deine lokalen Aufnahmen.

Meine Empfehlung: Behandle geteilte Aufnahmen wie Testcode. Reviewe sie, übertrage sie kontrolliert und prüfe nach Änderungen, ob die Ergebnisverträge noch stimmen. Normale getippte Werte können im Cache stehen; registrierte Secrets werden als Handles behandelt. Das ist kein Verzeichnis, das du ungeprüft öffentlich committen solltest.

Für eine frische Modellbewertung und einen strengeren CI-Lauf sind unterschiedliche Befehle sinnvoll:

E2E_TELEMETRY_DISABLED=1 npx e2e run --no-cache --workers 1 --retries 0
CI=1 E2E_TELEMETRY_DISABLED=1 npx e2e run --strict-cache --workers 1 --retries 0

`–strict-cache` ist kein Replay-only- oder Zero-Token-Modus. Eine bekannte veraltete Aufnahme scheitert mit REPLAY_STALE, statt für diese Abweichung an den Agenten zu übergeben. Neue Schritte ohne frühere Aufnahme, nicht vollständig replaybare Aufnahmen und live Modellurteile können weiterhin laufen. Diese Grenze steht im veröffentlichten Cache-Vertrag; Issue #938 fordert einen zusätzlichen Replay-only-Modus.

Was hat unser kleiner Praxistest bestätigt?

Der dokumentierte Testlauf vom 14. Oktober 2026 prüfte Installation, Locator-Aktionen, Assertions und den Replay-Vertrag im echten Browser. Für agent.act wurde ein eigener deterministischer StepExecutor verwendet, der einen Fixture-Button sucht und anklickt. Es gab keine simulierte LLM-Antwort und keinen Modellaufruf.

Die Umgebung nutzte bereits vorhandenes Chromium über lokalen Loopback-CDP, einen Worker und eine kleine lokale Demo-App. Das belegt nicht den automatischen Browserdownload, Mobile-Support oder die Fähigkeit eines LLMs, komplexe Oberflächen zu bedienen.

Die folgenden Eigenbelege liegen im lokalen redaktionellen Prüfpaket vor; sie sind hier nicht als öffentlich abrufbare Artefakte verlinkt. Die Prüfungen waren modellfrei und erlauben keine Aussage über typische LLM-Zuverlässigkeit oder Modellkosten.

Tatsächlich geprüfter Fall	Ergebnis	Beleg
Installation, CLI und Testauflistung	Version 0.20.0; vier Contract-Testfälle erkannt	Lokales Prüfprotokoll vom 14.10.2026
Verifizierter und unverifizierter act	Mit Folgeprüfung saved, ohne Folgeprüfung unconfirmed	Lokaler Report: browser-record/report.json
Warmer Replay	self-finalized, eine Aktion wiederholt, Aufnahme kept	Lokaler Report: browser-replay/report.json
Absichtlich falsche Count-Erwartung	Count: 2 statt tatsächlichem Count: 1: ASSERTION_FAILED, Exit 1	Lokaler Report: browser-negative/report.json
Umbenannter Button mit strict	target-not-found, REPLAY_STALE, Exit 2	Lokaler Report: browser-strict-drift/report.json
Derselbe geänderte Button ohne strict	Scripted Fallback, Assertion bestanden, neue Aufnahme; Report missed	Lokaler Report: browser-handoff-drift/report.json
Originale Upstream-Unit-Tests aus dem Release	115 von 115 bestanden, verteilt auf drei Cache-Testdateien	Lokales Vitest-Ergebnis: upstream-unit-results.json

Beim Fallback lief keine alte Aktion erfolgreich durch. Das war deshalb kein erfolgreiches Teil-Replay und erst recht keine demonstrierte LLM-Anpassung. Die lokalen Browserreports weisen für alle fünf Läufe null Model-Tokens und null Model-Calls aus: Wir haben den Harness geprüft, keine typische Modellkostenquote gemessen.

Eine externe Rezension auf andrew.ooo berichtet ebenfalls einen modellfreien Einstieg, allerdings gegen eine ältere Paketversion. Sie prüfte ausdrücklich nicht die KI-Agentenhälfte. In dieser Recherche wurde keine belastbare unabhängige Messung von LLM-Falsch-positiv-, Falsch-negativ-, Übergabe- oder Mobile-Fehlerquoten gefunden. Das ist eine Evidenzlücke, kein Beweis, dass solche Messungen nirgends existieren.

Wann reicht Playwright, wann lohnt die Mischung?

Eine gute Playwright-Suite besteht nicht aus willkürlichen CSS-Klassen und festen Sleeps. Die offiziellen Best Practices empfehlen bereits nutzernahe Locators, Auto-Waiting, Web-first Assertions und isolierte Tests. Für stabile Regressionen ist zusätzliche Laufzeit-Inferenz oft unnötig.

Kriterium	TesterArmy e2e	Playwright	Playwright Test Agents	Stagehand v4
Produktklasse	Test-Runner und SDK	Web-Testframework	Testplanung, -erzeugung und -reparatur	Browser-Automatisierungs-SDK
Modellzeitpunkt	Einzelne Testschritte zur Laufzeit	Kein Modell im regulären Testlauf nötig	Im Autoren-/Reparaturworkflow; erzeugte Tests laufen regulär	Bei AI-Aufrufen zur Laufzeit
Ergebnisprüfung	Genaue Assertions und semantische Judges	Konkrete Assertions	Erzeugte oder geänderte Assertions reviewen	Eigene Ergebnisprüfung zusätzlich planen
Wiederverwendung	Aufgezeichnete act-Aktionen	Wiederverwendbarer Testcode	Generierte Testdateien	Browserbase-Cache für geeignete act-/observe-/extract-Aufrufe
Native Mobile	Separater agent-device-Pfad	Mobile-Web-Emulation, nicht native App-Automation	Browser-Testworkflow	Kein gleichwertiger nativer Test-Runner aus der Vergleichsquelle belegt
Sinnvoll, wenn …	Ein variabler Ablauf harte Endkriterien hat	Stabile Regressionen klar spezifiziert sind	KI Tests schreiben soll, nicht ständig ausführen	Du agentische Browserautomation brauchst

Belege: e2e-Migrationsreferenz, Playwright Test Agents, Stagehand-v4-Cache-Dokumentation. Bei Stagehand setzt der beschriebene Cache Browserbase-Browser und API-Key voraus; mit einem lokalen Browser hat diese Cacheoption keine Wirkung. Das ist nicht derselbe lokale Replay-Vertrag wie bei e2e.

Für Playwright Test Agents ist noch eine Grenze wichtig: Der Healer kann laut Dokumentation auch einen Test als skipped hinterlassen. Prüfe Reparaturen und Skips gegen die Spezifikation, statt jede wieder grüne Suite als korrekte Reparatur zu akzeptieren.

Für die Praxis würde ich beide Runner zunächst nebeneinander betreiben und ihre Dateimuster sauber trennen. e2e ist kein API-identischer Ersatz für @playwright/test; die Migrationsreferenz nennt fehlende Funktionen und veränderte Semantik. Die grundlegende Browserautomation erklärt mein Playwright-Guide.

Welche Kosten und Einschränkungen bleiben?

Replay vermeidet act-Inferenz, nicht sämtliche Kosten

Das Framework hat keine Lizenzgebühr. Trotzdem bleiben Modellabrechnung, Browser-/CI-Zeit, Storage sowie Review- und Wartungsaufwand. Ein erfolgreicher act-Replay vermeidet für diesen Schritt Inferenz. Semantische Judges, neue Schritte und Agentenübernahmen können weiterhin Kosten verursachen. Der Promptcache eines Providers ist wiederum ein anderer Mechanismus als das Aktions-Replay.

Plane nicht mit einer pauschalen Ersparnisquote. Erfasse im Pilot Cold- und Warm-Läufe, Modellaufrufe, Input- und Outputtokens, Übergaben, Laufzeit und tatsächlich erkannte Fehler getrennt. Ohne validierte Providerabrechnung ist auch eine angezeigte Kostenschätzung kein belastbarer Gesamtpreis.

Der Resolver des geprüften Releases setzt für act standardmäßig maxSteps: 25 und maxModelCalls: 25. Begrenze diese Budgets bewusst. Der Runnerresolver sieht in CI standardmäßig einen Retry vor; im Pilot deaktivieren die oben gezeigten Befehle diesen ausdrücklich, damit ein fehlgeschlagener Erstversuch sichtbar bleibt.

Modellzugriff und Telemetrie sind unterschiedliche Datenflüsse

Der eingebaute Agent erhält Instruktionen, Accessibility-Tree, bereinigte URL und frühere Schritte; Screenshots kommen bei Bedarf oder aktiviertem Vision-Pfad hinzu. Das beschreibt die Security-Dokumentation. Es beweist weder weniger Tokens als bei jedem anderen Harness noch vollständige Vertraulichkeit.

Telemetrie ist standardmäßig eingeschaltet. Laut dokumentiertem Schema gehen Kennungen, Versions-/Systemdaten und Lauf-, Fehler- sowie Modellnutzungsaggregate an eu.i.posthog.com, nicht Testtitel, App-Inhalte oder Credentials. Die Umgebungsvariable in unseren Befehlen schaltet sie ab. Ein EU-Endpunkt allein ist kein DSGVO-Nachweis.

Für CI empfiehlt die Subscriptions-Dokumentation API-Keys statt rotierender Subscription-OAuth-Logins. Über E2E_OAUTH_CREDENTIALS eingebrachte Logins speichern erneuerte Tokens dort nicht zurück. Daraus folgt weder ein unbegrenztes Abo-Budget noch dauerhafte CI-Verfügbarkeit.

Secrets und Cache brauchen Review

Registrierte Secrets werden redigiert; ein Secret-Fill deaktiviert anschließende Screenshots für den Versuch. Videos und binäre Downloads sind dagegen nicht maskiert und können Secrets enthalten. Auch App-stdout/stderr in command.log bleiben original; transformierte oder nicht registrierte Werte können der Maskierung entgehen.

Die Security-Regeln nennen außerdem keine Origin-Allowlist: Ein Agent kann einer Navigation zu einer anderen Website folgen und dort Secrets verwenden. Tests, Konfiguration und Erweiterungen laufen unsandboxed mit den Rechten des ausführenden OS-Nutzers. Verwende deshalb Testaccounts mit begrenzten Rechten und für nicht vertrauenswürdige Pull Requests eine externe Sandbox ohne wertvolle Secrets oder Schreib-Tokens.

Native Mobile bedeutet zusätzliche Infrastruktur

Für native Apps brauchst du Xcode mit iOS-Simulator-Runtime oder Android-SDK und Emulator. Physische iPhones benötigen unter anderem Trust, Developer Mode und einen signierten Automatisierungsrunner. Verschiedene Geräteeinstellungen bleiben simulator-only. Außerdem entspricht der Zustand zwischen Tests nicht automatisch einem frischen Browsercontext. Die Mobile-Anleitung dokumentiert diese Unterschiede; eigene Mobile-Tests wurden hier nicht ausgeführt.

Live-Dokumentation und installierter Stand können auseinanderlaufen

Ein geschlossenes Issue beweist nicht, dass sein Fix schon im veröffentlichten Paket steckt. Beim Next.js-Route-Announcer beschreibt die Live-Cache-Dokumentation bereits ein Verhalten, dessen Erklärung im geprüften Paketstand noch fehlt; dazu gehört Issue #1057. Es wurde kein eigener Next.js-Test durchgeführt. Prüfe daher nach Updates erneut Paket, Changelog und deinen konkreten Flow, statt main-Aussagen ungeprüft auf Stable zu übertragen.

Wie setzt du einen sinnvollen Pilot auf?

1. Wähle einen begrenzten Flow. Nimm beispielsweise einen wechselnden Einrichtungsdialog, nicht sofort die komplette Checkout- oder Berechtigungssuite.
2. Definiere den Ergebnisvertrag vorher. Welche Inhalte, Mengen, Zustände oder Backend-Ergebnisse müssen stimmen? Ein allgemeines „sieht erfolgreich aus“ reicht nicht.
3. Starte modellfrei. Prüfe App, Locators und Assertions. Erst dann ersetzt du eine variable Strecke durch ein Agentenziel.
4. Baue eine Negativkontrolle ein. Ändere bewusst einen erwarteten Wert oder erzeuge in der Testapp ein falsches Ergebnis. Der Test muss dann fehlschlagen. Stelle danach den korrekten Zustand wieder her.
5. Vergleiche frisch und aufgezeichnet. Prüfe mit --no-cache den Agentenpfad und anschließend den Replay. Behalte genaue Folgeprüfungen in beiden Fällen bei.
6. Reviewe UI-Änderungen und Aufnahmen. Ein neuer grüner Ablauf darf nicht stillschweigend die ursprüngliche Spezifikation abschwächen.
7. Entscheide anhand eigener Daten. Behalte stabile Playwright-Tests. Übernimm den Pilot erst, wenn Fehlererkennung, Aufwand und Laufkosten für deinen Fall nachvollziehbar sind.

Das ist eine Einführungsmethode, kein Herstellerbenchmark und kein Versprechen auf weniger Wartung.

FAQ: Häufig gestellte Fragen zu TesterArmy e2e

Ist TesterArmy e2e kostenlos?

Das Open-Source-Framework steht unter Apache-2.0. Modellzugriff und Infrastruktur können trotzdem Kosten verursachen. Die gehostete Plattform ist ein separates Angebot.

Ersetzt e2e Playwright?

Nicht pauschal. Das Web-Paket baut auf Playwright auf, verwendet aber einen eigenen Runner und eine eigene API. Die Migrationsreferenz empfiehlt den Parallelbetrieb und beschreibt Unterschiede.

Braucht mein erster Test einen API-Key?

Ein Locator-Test ohne Agentenschritte braucht laut Quickstart keinen Modellzugang. Für den eingebauten Agenten musst du anschließend Modell und Authentifizierung konfigurieren.

Sind KI-Assertions deterministisch?

Die semantischen Urteile des eingebauten Agenten sind modellabhängig und können falsch sein. Verwende für genaue fachliche Kriterien Locator-/Engine-Assertions; die Cache-Anleitung trennt beide Prüfarten.

Läuft --strict-cache garantiert ohne Modell?

Nein. Es blockiert bestimmte Abweichungen vorhandener Aufnahmen, ist aber kein allgemeiner Replay-only-Modus. Neue Schritte und live Judges bleiben nach dem Cache-Vertrag möglich.

Was passiert nach einer UI-Änderung?

Findet der Replay ein Control oder den erwarteten Endzustand nicht mehr passend, kann der Agent übernehmen; unter strict scheitern die dokumentierten Abweichungen. Fachliche Änderungen außerhalb der geprüften Anker müssen deine eigenen Assertions erkennen.

Kann e2e meinen Hermes-ChatGPT-Login übernehmen?

Eine automatische Übernahme ist nicht bestätigt. e2e dokumentiert einen eigenen Login; in der eigenen Prüfung wurden weder Login noch Modellzugriff durchgeführt.

Funktioniert native Mobile auf jedem Rechner?

Nein, Toolchain, Plattform und Gerät müssen passen. Die Mobile-Dokumentation unterscheidet Simulatoren, Emulatoren und angeschlossene Geräte; nicht alle Funktionen stehen überall zur Verfügung.

Fazit

Teste TesterArmy e2e als gezielte Ergänzung für einen variablen Ablauf, nicht als pauschalen Ersatz deiner Playwright-Suite. Der interessante Mechanismus ist die Verbindung aus Agentenziel, konkreter Folgeprüfung und kontrolliertem Replay; eine Wartungs- oder Kostenersparnis musst du trotzdem selbst nachweisen. Die Playwright-Grundlagen und die AI-Harness-Einordnung helfen bei der technischen Abgrenzung, Superpowers für Coding-Agenten bei Test- und Reviewdisziplin.

Quellen

Primärquellen und Vergleichsdokumentation

• TesterArmy-e2e-Repository und Release e2e@0.20.0.
• Apache-2.0-Lizenz am Release-Commit.
• npm-Manifeste: e2e@0.20.0, @e2e-dev/web@0.14.0, @e2e-dev/mobile@0.12.0.
• Einstieg: Quickstart, Modelle, Subscriptions und CI-Authentifizierung, Executors.
• Replay: Live-Cache-Dokumentation und versionsgebundener Cache-Vertrag.
• Grenzen: Security, Telemetrie, Mobile, Playwright-Migration.
• Defaults: Agentenresolver und Runnerresolver.
• Issues: #1000, Modellidentität und Cache, #938, Replay-only-Wunsch, #1057, Next.js-Route-Announcer. Issue-Berichte sind keine eigenen Reproduktionen.
• Vergleich: Playwright Best Practices, Playwright Test Agents, Stagehand-v4-Caching.

Eigene technische Prüfungen

• Lokales redaktionelles Prüfpaket vom 14.10.2026: Prüfprotokoll, Versions-Snapshot, Quellen-/Versionsabgrenzung, fünf Browserreports und Vitest-Ergebnis. Die Artefakte wurden für diesen Artikel ausgewertet, sind aber nicht öffentlich gehostet.
• Die 115 bestandenen Unit-Tests stammen aus drei originalen Cache-Testdateien des Release-Commits; beispielsweise ist die Upstream-Testdatei öffentlich lesbar. Sie dokumentiert den Testcode, nicht unsere lokale Ausführung.

Externe Praxisperspektive

• andrew.ooo: e2e Review. Externe modellfreie Reproduktion gegen einen älteren Paketstand, kein LLM-Zuverlässigkeitsbenchmark.

Recherche- und Prüfstand: 14. Oktober 2026. Live-Dokumentation kann dem veröffentlichten Paket voraus sein; versionsgebundene Aussagen beziehen sich auf das oben verlinkte Release.