test-trust

Sagt KI-Codeagenten (Claude Code, Codex, OpenHands, Cursor oder einem lokalen Modell – agentunabhängig über MCP, das Model Context Protocol) nicht nur, welche Tests eine Änderung abdecken, sondern auch, ob diese Tests tatsächlich vertrauenswürdig sind, eine Regression genau dort zu finden.

„CI ist grün“ und „diese Änderung ist sicher“ werden heute von jedem Agenten als dasselbe behandelt. Das sind sie nicht. Ein Test, der eine Funktion abdeckt, ist nicht dasselbe wie ein Test, der tatsächlich fehlschlagen würde, wenn diese Funktion kaputtgeht – zu stark gemockte Tests, Snapshot-Tests, die einfach neu aufzeichnen, was auch immer die neue Ausgabe ist, und Tests ohne Assertions zeigen alle grün, fangen aber nichts.

So funktioniert’s

1. Mutationstesting (nutzt ausgereifte vorhandene Engines, nicht neu implementiert –
   mutmut für Python, StrykerJS für JS/TS, gremlins für Go, cargo-mutants für
   Rust): absichtlich kleine Fehler in den geänderten Code einbauen
   und prüfen, ob die abdeckenden Tests tatsächlich fehlschlagen. Die
   Testauswahl pro Mutant stammt aus den eigenen Coverage-Daten der jeweiligen
   Engine und ist hier nicht neu implementiert – mutmut und Stryker (wo ein
   unterstützter Runner vorhanden ist: jest/mocha/vitest) wählen nur die
   spezifischen Tests aus, die den jeweiligen Mutanten abdecken; gremlins und
   cargo-mutants überspringen Mutanten ohne Coverage, führen für jeden
   Mutanten mit irgendeiner Coverage jedoch die vollständige relevante Test-Suite
   erneut aus – ein gröberer (und bei großen Repos langsamerer), aber
   dennoch korrekter Mechanismus.

2. Diff-Scoping (unser Ansatz): bildet die geänderten Zeilen eines
   Git-Diffs über den jeweiligen Parser der Sprache auf die umgebende Funktion ab,
   sodass sowohl der Mutationslauf als auch der Vertrauenswert auf das
   eingegrenzt werden, was sich tatsächlich geändert hat, nicht auf eine ganze Datei/ein ganzes Repo.

3. Fusion (der neue Teil, sonst nirgends gebaut – verifiziert): bündelt
   das oben Genannte zu einem Vertrauenswert pro geänderter Funktion,
   bereitgestellt als MCP-Tool, das jeder Agent aufrufen kann, bevor er einen
   grünen Testlauf als Beleg für Sicherheit behandelt.

Live-Demonstrationen: Siehe examples/weak-test-fixture/ (Python),
examples/weak-test-fixture-js/ (JS), examples/weak-test-fixture-go/ (Go),
examples/weak-test-fixture-rust/ (Rust),
examples/plug-and-play-fixture/ (ganz ohne Konfiguration) sowie
examples/multi-file-fixture-js/ (eine Funktion, die ein Schwestermodul
importiert und belegt, dass Mutation-Scoping die Über­datei-Importe nicht bricht):
eine Funktion, die von einem Test abgedeckt wird, der heute grün ist, aber
einen echten Bug nicht finden würde.

Related MCP server: sumo-qa

Gegen echte Repos validiert, nicht nur gegen Fixtures

Jedes Fixture oben ist eine Spielerei. Bevor diesem Konzept vertraut wurde,
den Tool wurde außerdem ohne Konfiguration gegen echte, externe, unveränderte
Repositories in allen vier Sprachen testiert: psf/requests (Python,
37 echte Funktionen bewertet, z. B. resolve_proxies korrekt mit
Vertrauenswert 0.0 markiert – tatsächlich referenziert kein einziger Test
darauf), kind-of (JS, ~50M wöchentliche Downloads, isArray und
isRegexp markiert, obwohl alle 36 Tests bestehen),
dustin/go-humanize (Go) und chronotope/humantime (Rust, eine echte
Multi-Modul-Crate – bestätigt, dass Mutation-Scoping auch bei echten
Cross-Module-Cod nicht bricht, nicht nur bei unserem eigenen Fixture). Dieser
Prozess hat mehrere echte Fehler in drei der vier Felder aufgedeckt und behen:
einen Fall, in dem ein fehlgeschlagener Mutationslauf stillschweigend als
falscher 100 %-Vertrauenswert gemeldet wurde, und einen Skalierungsbug, bei dem
eine auf eine Datei beschränkte Anfrage stattdessen stillschweigend ein ganzes
gepackertes Paket mutierte. Rusts Repo-Real-Check deckte keinen neuen Bug auf,
konsistent damit, dass cargo-mutants -f der sauberste, direkt versehenste
Scoping-Mechanismus der vier ist. Den vollständigen Bericht findest du in
docs/architecture.md.

Externe Tools, die dieses Tool einbindet (einmal installieren, pro verwendeter Sprache)

• Python: mutmut – wird automatisch als Abhängigkeit dieses Projekts installiert.

• JS/TS: @stryker-mutator/core – wird beim ersten Aufruf automatisch über npx geholt.

• Go: gremlins – go install github.com/go-gremlins/gremlins/cmd/gremlins@latest

• Rust: cargo-mutants – cargo install cargo-mutants

Ausprobieren

Noch nicht auf PyPI veröffentlicht. Alle Befehle unten setzen einen lokalen Klon dieses Repos und die Ausführung im darin (uv); von außerhalb dann uv run --directory <path> ..., wie weiter unten im Agent-Einbettungsbeispiel. Sobald es veröffentlicht ist, reduziert sich das auf ein einfaches pip install test-trust / ux test-trust, das von überall ausgeführt werden kann – ohne Klon, ohne Pfad zum Merken, ohne uv run --directory. Dieser einzelne Schritt ist der letzte zwischen „funktioniert, mit Einrichtung“ und „wirklich leicht zu übernehmen“; nichts daran, wie sich das Tool verhält, ändert sich, nur sehr man es nutzt.

Benötigt Python 3.11+ und uv. Sprachspezifische Mutationsengines (siehe oben) werden nur für die Sprachen gebraucht, die du tatsächlich nutzt – das Python-Beispiel unten braucht nichts über uv sync hinaus.

uv sync
uv run test-trust check examples/plug-and-play-fixture inventory.py

Keine Setup-Datei, kein manuellerMutationstest-Lauf – dieser eine Befehl erkennt die Sprache automatisch, schreibt automatisch die Konfiguration, führt die TestType automatisch mit einem Schwerpunkt auf der eigenen Testdatei aus und gibt den Vertrauenswert aus.

Für eine andere Datei oder ein andere Repo:

uv run test-trust check <path-to-repo> <source-file> [--changed-file F] [--base-ref REF] [--threshold T]

Schwellenwert ändern (Standard 0.5) – was als ausreichend getestet gilt. Wiederholt erhöht (z. B. 0.8) markiert alles, was unter der nahezu vollständigen Mutationscoverage liegt; nach unten senken, um nur die größten Abdeckungslücken zu loggen. Derselbe Parameter, drei Oberflächen:

• CLI: --threshold 0.8, wie oben zu sehen.

• MCP-Tool: threshold ist ein get_test_trust-Argument, z. B. get_test_trust(repo_path=..., source_file=..., threshold=0.8). Den
  rufst du nicht selbst auf, sondern der Agent tut es; „setzen“ bedeutet
  der, den Agenten dazu zu bringen, das zu tun (im Prompt oder als
  permanente Ansage in CLAUDE.md). Ohne Angabe wird 0.5 verwendet.

• GitHub Action: der Eingabewert low-trust-threshold in deiner Workflow-Datei:

- uses: ./.github/actions/test-trust-pr
  with:
    github-token: ${{ secrets.GITHUB_TOKEN }}
    low-trust-threshold: "0.8"

In einen Agenten einbetten

Einmalige Einrichtung, die global statt pro Projekt registriert wird – weil repo_path bei jedem Aufruf ein Parameter ist und nicht beim Start feststeht, reicht eine Registrierung, um jedes später geöffnete Projektent, nicht nur das Projekt, in dem sie stattgefunden hat. Für Claude Code, sollte ~/.claude.json (Benutzerebene, nicht der .mcp.json des Projekts eintragen:

{
  "mcpServers": {
    "test-trust": {
      "command": "uv",
      "args": ["run", "--directory", "/absolute/path/to/test-trust", "test-trust", "mcp"]
    }
  }
}

Die gleiche command/args-Form funktioniert für Codex, Cursor oder einen beliebigen anderen MCP-Client – siehe docs/embedding.md für diese und für was die PyPI-Veröffentlichung (uvx test-trust mcp, kein lokaler Pfad nötig) ändert.

Danach ist es im Alltag unsichtbar: Der Agent ruft get_test_trust selbst auf, mitten in der Aufgabe, genauso wie er bereits seine File-Read- oder Bash-Tools nutzt – self per rufst es nicht direkt.

Oder auf jedem PR ausführen, ohne Agenten nötig

.github/actions/test-trust-pr bewertet jede geänderte, unterstützte Datei in einem PR und postet (oder aktualisiert bei späteren Pushes) einen Kommentar: Flaggt jede Funktion, deren bestehende Tests eine Regression dort nicht wirklich fangen würden. Nützlich für jedes Review-Team, ob jemanden den Agenten nutzt oder nicht. .github/workflows/test-trust.yml ist das funktionierende Beispiel, das komplett End-to-End gegen echte Commits in einem echten Repo verifiziert Durchlaufen-Enderkennung, Bewertung und beide Kommentarvarianten „Aller klar“ und „Problem markiert“; lediglich der lebende GitHub-APICall selbst ist ungetestet, da immer ein echter PR dafür nötig ist.

Entwickeln

uv sync
uv run pytest tests/            # this project's own unit test suite
uv run test-trust check <repo> <file>   # exercise it against real code

testsenfonds deckt die deterministische Logik ab (Diff-Scoping, Vertrauenswert-Aggregation, Sprach-Autodetection, Report-Adapter der Mutations-Engines) mit gebauten Fixtures – schnell, keine externen Mutationstests erforderlich, und genau diese Suite läuft in der CI (.github/workflows/ci.yml). Sie ersetzt die reale Repo-Validierung oben nicht – das war eine manual, einmalige Übung, die während der Entwicklung erfolgte (echte externe Klons, echte Engines installiert), sodass CI das nicht bei jedem Push erneut. Dies würde Automatisierung übernehmen; es ist noch nicht fertig.

MIT-lizenziert.