TestTrout

Der Testassistent für KI-gebaute Apps.

Nutze es als App oder übergib es deinem Coding-Agenten über MCP. In beiden Fällen schreibt es die Tests, die deine App nie hatte, und meldet, wenn sie brechen.

Forellen sind Indikatorarten. Sie leben nur in sauberem, gut mit Sauerstoff versorgtem Wasser – findest du eine in einem Bach, weißt du, dass das Wasser gesund ist, ohne es selbst zu testen.

Genau das ist eine gute Testsuite: keine lästige Pflicht, sondern ein Signal, das du auf einen Blick lesen kannst.

Das Problem

Coding-Agenten liefern schnell. Sie brechen aber auch leise Dinge, und die Apps, die sie bauen – Lovable, v0, Bolt, handgerolltes React auf Vercel – haben fast nie Tests. So endet die Schleife mit „sieht für mich gut aus" von dem Ding, das gerade den Code geschrieben hat.

TestTrout schließt diese Schleife. Es liest das Repository, verbindet sich mit der laufenden Deployment, ermittelt, was ungetestet ist und in welcher Reihenfolge es wichtig ist, schreibt echte Tests, führt sie aus und meldet Ergebnisse, auf die du tatsächlich reagieren kannst.

Related MCP server: Lastest

Zum Laufen bringen

pip install testtrout
trout up

Speicher, ein Worker und die Oberfläche unter localhost:7411. Kein Docker, kein Daemon, keine Datenbank zum Installieren – SQLite unter ~/.testtrout, Worker im Prozess. Keinerlei API-Schlüssel. Hier wird kein Modell aufgerufen.

So funktioniert es

Füge ein Projekt hinzu – einen Ordner auf diesem Rechner und die URL, unter der es deployed ist.

trout add ~/code/my-app --url https://my-app.vercel.app

Dann vier Schritte, die zugleich vier Befehle sind:

trout look     # read the code, ask the deployment, work out what is testable
trout facts    # what I still need from you — all optional
trout build    # write the baseline and prove it
trout run      # re-run it and report what changed

Eine Baseline ist das, was dein Deployment heute tut. TestTrout zeichnet das auf und stellt sicher, dass es weiterhin passiert. Es weiß nicht, ob das aktuelle Verhalten korrekt ist – das hat ihm niemand gesagt – und es wird nie danach fragen. Es weiß, was das Verhalten ist, und es bemerkt den Tag, an dem sich das ändert.

Genau diese eine Regel ist der Grund, warum es kein Interview, keine Genehmigungswarteschlange und keine Liste von Fragen zu deinem Produkt gibt. Die einzigen Dinge, nach denen es fragt, sind konkrete Werte, die es nicht selbst herausfinden kann:

Jede Antwort ist in Sekunden gegeben, jede ist optional, und jede sagt, was sie freischaltet. Gib nur eine URL und sonst nichts, und du bekommst jede Seite, die abgemeldet lädt – was bei den meisten Apps bereits eine nützliche Suite ist.

Alles, was es herausfindet, wird als Artefakt in der Seitenleiste aufbewahrt – die Projektkarte, das Formular, der Testplan, die Baseline-Suite – damit nichts Wichtiges drei Bildschirme tief in einem Chat-Verlauf verschwindet.

Oder bleib in deinem Coding-Agenten

Die App ist ein Einstieg, nicht der einzige. Alles, was sie tut, ist als typisierte MCP-Tools und als CLI-Befehle verfügbar, sodass niemand, der seinen Editor nicht verlassen möchte, das nicht tun muss:

pip install 'testtrout[mcp]'
trout mcp /path/to/your/project

Richte deinen Agenten auf das Skill in .claude/skills/ aus oder sag ihm:

Nutze den TestTrout-MCP-Server. Schau dir das Repo an, sag mir, was es noch von mir braucht, dann baue die Baseline und führe sie aus.

Sieben Tools, an ein Projekt gebunden, damit ein Agent nicht am falschen Repository handeln kann:

Plus trout://map, trout://facts, trout://plan, trout://config, trout://scenarios als Ressourcen, damit Massenzustand den Kontextfenster eines Agenten nie überfüllt.

Was es versteht

trout look liest Code ohne jeglichen Netzwerkzugriff, ist also sicher bei einem Repo, das du gerade geklont hast. Bei einer typischen Supabase-App findet es:

Es sagt dir auch, wenn eine Tabelle aus Browser-Code ohne Row-Level-Security geschrieben wird – das heißt, sie ist über den Anon-Key weltweit beschreibbar. Das ist meistens eine Neuigkeit.

Es fragt nie nach deiner Datenbank

Tests erreichen deine App so, wie ein Nutzer es tut: HTTP gegen deine Endpunkte und einen echten Browser gegen deine Oberfläche. Die Anmeldung läuft über dein eigenes Login-Formular, das trout look einmal lokalisiert, damit Tests ein bekanntes Formular abspielen statt zu raten.

Das Ganze braucht also eine URL und zwei Testkonten. Kein Anon-Key, keine Service-Rolle, keine Projekt-Zugangsdaten – nichts, was die meisten Teams einem Testtool vernünftigerweise verweigern würden.

Autorisierung ist trotzdem abgedeckt, und zwar argumentativ besser: Mit zwei normalen Konten angemeldet, darf das eine nicht sehen, was das andere sieht. Das übt deine Richtlinien und alles, was deine Anwendung darüberlegt – genau das, was ein echter Nutzer vorfindet.

Warum die Tests vertrauenswürdig sind

Es baut eine Baseline auf, keine Per-PR-Vermutungen. Ein Test, der aus dem Code abgeleitet ist, den du gerade geändert hast, behauptet, dass das neue Verhalten per Konstruktion korrekt ist – er kann keine Regression erkennen. TestTrout zertifiziert eine Suite zuerst gegen eine funktionierende Deployment, damit ein Fehlschlag etwas bedeutet.

Kein Modell, nirgendwo. Nicht beim Scannen, nicht bei der Planung, nicht beim Schreiben eines Tests. Jede Assertion führt auf etwas zurück, das die Deployment tatsächlich getan hat – deshalb erzeugen dieselben Eingaben immer dieselbe Suite und deshalb gibt es keinen API-Schlüssel zu konfigurieren.

Jede Assertion trägt ihre Herkunft, und in einer Baseline ist sie immer observed – mit den Belegen, die in die generierte Datei geschrieben werden:

// observed: the page title when /orders was loaded
await expect(page).toHaveTitle('Orders');
// observed: seen on /orders at baseline
await expect(page.getByTestId('orders-table')).toBeVisible();

Es sendet immer nur ein GET. Endpunkt-Tests spielen die Anfrage ab, die der Probe gemacht hat, unabhängig davon, welche Methoden der Endpunkt deklariert – so kann das Ausrichten auf Produktion dort nichts verändern.

Ein Fehlschlag wird klassifiziert, bevor er gemeldet wird. Nur assertion_failure ist ein Produktsignal. Auth-Fehler, unerreichbare Datenbanken und blockierte Drittanbieter-Aufrufe betreffen die Testumgebung, und ein unschlüssiger Lauf wird nie zu einem Bestehen aufgewertet.

Alles vom Terminal aus

trout add ~/code/my-app --url https://my-app.vercel.app
trout look          # read the code, ask the deployment
trout facts         # what I still need — all optional
trout build         # write the baseline and prove it
trout run           # re-run it; a failure means behaviour changed

Jeder Befehl unterstützt --json. Vollständige Anleitung in docs/setup.md.

Wie es Dinge speichert

Deine Testsuite bleibt in deinem Repository, committet und überprüfbar:

.trout/scenarios/*.yaml    what each test asserts, in plain language
.trout/facts.yaml          what was asked for — never a secret value
.trout/plan.yaml           what can be tested, and what is waiting
.trout/config.yaml         deployments and env: references, never secrets
tests/trout/               generated Playwright and Vitest files

Laufverlauf, Coverage über die Zeit und die Job-Warteschlange liegen in SQLite unter ~/.testtrout. Diese Trennung ist beabsichtigt: Die Suite gehört neben den Code, wo ein Pull-Request sie überprüfen kann, und die Fragen, die Dateien nicht beantworten können – wird dieser Test flakier, steigt die Coverage – gehören in eine Datenbank.

Optionale Web-Ansicht

trout web

Coverage auf einen Blick, die sortierte Lückenliste, Szenario-Review, Laufverlauf mit Belegen, Live-Log. Dieselben .trout/-Dateien wie die CLI – keine Datenbank, nichts gehostet, nur Loopback. Vollständig optional; die CLI und MCP sind für sich genommen vollständig.

Sicherheit

Das Tool braucht deine Datenbank-Zugangsdaten und kann deine Deployment steuern, daher sind die Garantien im Code erzwungen statt nur dokumentiert:

• Produktion ist standardmäßig schreibgeschützt. Mutierende Anfragen werden auf der Netzwerkebene blockiert, es sei denn, ein Einstiegspunkt ist explizit als disposable markiert. Die Absicherung sitzt unterhalb der Navigation, denn „nur eine Seite laden ist schreibgeschützt" ist falsch – viele dieser Apps schreiben beim Mount. Kein Agent und kein Web-Klick kann diese Einstellung ändern.

• Drittanbieter werden abgefangen. Ein Testlauf kann keine Karte belasten oder einen Kunden mailen. Nicht abgeglichene ausgehende Anfragen schlagen laut fehl; ein Mock, der still nichts abgleicht, ist der Weg, wie eine Suite grün meldet, während sie nichts testet.

• Geheimnisse bleiben aus committeten Dateien heraus. .trout/config.yaml enthält nur env:-Referenzen. Werte liegen in einer gitignored .env.

• Nichts ist gehostet, und nichts verlässt deinen Rechner. Es gibt kein Modell zum Aufrufen und kein Konto zum Anlegen. Keine Telemetrie.

Unterstützte Stacks

React + Vite (Lovable, v0, Bolt) und Next.js App Router, in TypeScript, mit Supabase, überall deployed, wo HTTP erreichbar ist. Auth über Supabase, Clerk oder NextAuth.

Bewusst schmal. Tiefe bei einem Stack schlägt flache Abdeckung vieler – und diese Codebasen sind regelmäßig genug, dass statische Analyse auf ihnen wirklich genau ist. Andere Stacks sind nur einen Adapter entfernt: siehe docs/adapters.md.

Roadmap

Mitwirken

Ein Framework, Auth-Provider oder Test-Runner hinzuzufügen bedeutet, ein Protokoll zu implementieren und einen Einstiegspunkt zu registrieren – kein Fork nötig. Siehe CONTRIBUTING.md und docs/adapters.md.

Die vollständige Testsuite läuft offline ohne API-Schlüssel. Das ist beabsichtigt und erhaltenswert.

Lizenz

Apache 2.0