TestTrout

Der Testassistent für KI-gebaute Apps.

Führe es als App aus oder übergib es deinem Coding-Agenten über MCP. So oder so schreibt es die Tests, die deine App nie hatte, und meldet, wenn sie fehlschlagen.

Forellen sind eine Indikatorart. Sie leben nur in sauberem, gut durchlüftetem 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 Dinge, und die Apps, die sie bauen – Lovable, v0, Bolt, handgeschriebenes React auf Vercel – haben fast nie Tests. Die Schleife endet also mit "sieht 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-Umgebung, ermittelt, was ungetestet ist und in welcher Reihenfolge es wichtig ist, schreibt echte Tests, führt sie aus und liefert Ergebnisse, auf die du wirklich reagieren kannst.

Related MCP server: Lastest

So bringst du es zum Laufen

pip install testtrout
trout up

Das startet alles: Speicher, einen Hintergrund-Worker und die Oberfläche unter localhost:7411. Kein Docker, kein Daemon, keine Datenbank zum Installieren – der Speicher ist SQLite unter ~/.testtrout und der Worker läuft im selben Prozess.

Verknüpfe dann ein Repository, über die Oberfläche oder das Terminal:

trout link ~/code/my-app          # a folder you already have
trout link --github owner/name    # cloned with your GitHub token

Das Verknüpfen eines lokalen Ordners verändert ihn nie. Ein Scan startet automatisch, und der Setup- Tab enthält jede Einstellung: Deployments, Supabase, Testkonten, Modellanbieter.

Zwei Dinge machen das sicher und nützlich:

Es zeigt dir, welche Anmeldedaten deine App braucht, ermittelt durch das Lesen deines Quellcodes – welche Variablen sie verwendet, wofür sie wahrscheinlich dienen und in welcher Zeile sie auftauchen. Nichts wird neu hergeleitet, was der Code bereits selbst preisgibt.

Ein unvollständiger Satz ergibt eine unvollständige Testsuite. Mit nur einer URL kannst du API-Tests sondieren und ausführen; füge einen Anon-Key und ein zweites Konto hinzu, und Autorisierungstests werden möglich. Jede blockierte Fähigkeit benennt genau das eine, was noch fehlt – nie "konfiguriere es einfach richtig".

Geheime Werte werden in eine gitignorierte .env geschrieben; die fest eingecheckte Konfiguration enthält nur env:NAME-Verweise, und ein wörtliches Geheimnis, das in ein Konfigurationsfeld getippt wird, wird abgelehnt.

Oder bleib in deinem Coding-Agenten

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

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

Weise deinen Agenten auf das Skill in .claude/skills/ hin oder sag ihm:

Nutze den TestTrout-MCP-Server. Scanne das Repo, zeig mir, was ungetestet ist, sortiert nach Wichtigkeit, entwirf Tests für die Top fünf und führe sie aus.

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

Plus trout://surfaces, trout://intent, trout://config, trout://scenarios als Ressourcen, damit der Kontext des Agenten nicht überquillt.

Was es versteht

trout scan ist vollständig deterministisch – kein Modell, kein Netzwerk, sicher auf einem frisch geklonten Repo. Bei einer typischen Supabase-App findet es:

Es zeigt dir auch, wenn eine Tabelle aus Browser-Code heraus beschrieben wird, ohne Zeilenschutz auf Datenbankebene – das heißt, sie ist über den Anon-Key weltweit beschreibbar. Das ist meistens eine Neuigkeit.

Warum die Tests vertrauenswürdig sind

Es baut eine Basislinie, keine PR-für-PR-Vermutungen. Ein Test, der aus dem Code abgeleitet ist, den du gerade geändert hast, behauptet das neue Verhalten korrekt per Konstruktion – er kann keine Regression übersehen. TestTrout zertifiziert eine Testsuite gegen eine funktionierende Bereitstellung zuerst, sodass ein Fehlschlag etwas bedeutet.

Deterministischer Kern, Modell an den Rändern. Scannen, Priorisieren, Ausführen und Fehler- klassifizierung rufen nie ein Modell auf. Das Modell interpretiert nur deine Absicht, verfeinert Formulierungen und wählt aus, welche beobachteten Elemente behauptet werden sollen. Jede Priorisierung ist die Summe benannter Beiträge:

critical  authorization  A user cannot read another user's rows in payments   100
  · critical surface
  · policy: exists (select 1 from orders o where o.id = payments.order_id …)

Jede Behauptung trägt ihre Herkunft. derived aus einer Richtlinie, observed in einem echten Browser oder inferred durch ein Modell – und allein aus dem Modell abgeleitet kann nie einen Lauf blockieren.

Ein Fehlschlag wird klassifiziert, bevor er gemeldet wird. Nur assertion_failure ist ein Produkt- signal. Anmeldefehler, nicht erreichbare Datenbanken und blockierte Drittanbieter-Aufrufe betreffen die Umgebung, und ein nicht aussagekräftiger Lauf wird nie zu einem Fehlschlag hochgestuft.

Alles über das Terminal

trout scan          # understand the code
trout init          # connect a deployment
trout gaps          # what's missing, ranked, with reasons
trout run           # execute, with evidence behind every result

Jeder Befehl unterstützt --json. Die vollständige Anleitung findest du in docs/setup.md.

Wie es Dinge speichert

Deine Testsuite bleibt in deinem Repository, eingecheckt und reviewbar:

.trout/scenarios/*.yaml    what each test asserts, in plain language
.trout/config.yaml         deployments and env: references, never secrets
tests/trout/               generated Playwright and Vitest files

Laufhistorie, Abdeckung im Zeitverlauf und die Job-Warteschlange liegen in SQLite unter ~/.testtrout. Diese Aufteilung ist bewusst: Die Suite gehört neben den Code, wo eine Pull-Request sie reviewen kann, und die Fragen, die Dateien nicht beantworten können – wird dieser Test flakier, steigt die Abdeckung? – gehören in eine Datenbank.

Optionale Web-Ansicht

trout web

Abdeckung auf einen Blick, die priorisierte Lückenliste, Szenario-Review, Laufhistorie mit Beweisen, Live-Log. Dieselben .trout/-Dateien wie bei der CLI – keine Datenbank, nichts Gehostetes, nur Loopback. Komplett optional; CLI und MCP sind für sich genommen vollständig.

Sicherheit

Das Tool braucht deine Datenbank-Anmeldedaten und kann deine Bereitstellung steuern, daher werden die Garantien im Code durchgesetzt statt nur dokumentiert:

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

• Drittanbieter werden abgefangen. Ein Testlauf kann keine Karte belasten oder einen Kunden anschreiben. 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 eingecheckten Dateien heraus. .trout/config.yaml enthält nur env:-Verweise. Die Werte liegen in einer gitignorierten .env.

• Nichts wird gehostet. Nichts verlässt deinen Rechner außer Aufrufen an den Modellanbieter, den du gewählt hast. Keine Telemetrie.

Modellanbieter

Anthropic, OpenAI oder Kimi – oder jeder OpenAI-kompatible Endpunkt über base_url.

model:
  provider: anthropic
  api_key: env:ANTHROPIC_API_KEY

Die Analyse ruft nie ein Modell auf, daher funktionieren trout scan, trout gaps und trout run alle ganz ohne Schlüssel.

Unterstützte Stacks

React + Vite (Lovable, v0, Bolt) und Next.js App Router, in TypeScript, mit Supabase, bereitgestellt an einem beliebigen über HTTP erreichbaren Ort. Auth über Supabase, Clerk oder NextAuth.

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

Roadmap

Mitwirken

Ein Framework, einen Auth-Anbieter oder einen 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-Key. Das ist beabsichtigt und erhaltenswert.

Lizenz

Apache 2.0