vacuous-tests-mcp

Ein MCP-Server, der Tests findet, die unabhängig vom Code immer bestehen.

Ein inhaltsloser Test ist schlimmer als ein fehlender. Ein fehlender Test ist sichtbar fehlend. Ein inhaltsloser Test sitzt in der Suite, läuft grün, zählt in der Gesamtzahl und wird als Beleg angeführt, dass ein Verhalten abgedeckt ist – während er nichts prüft. Es ist Abdeckung, die unsichtbar fehlt, und er überlebt genau die Situationen, für die Tests existieren.

Sie sind leicht aus Versehen zu schreiben und schwer durch Lesen zu erkennen, denn ein inhaltsloser Test und ein echter sehen oft fast identisch aus.

Der Fall, aus dem das entstanden ist

Eine Rust-Datei mit 6,764 Zeilen in einem Projekt, dessen Testsuite bereits regelmäßig manuell geprüft wurde. Zwei Tests darin:

// flagged
const SRC: &str = include_str!("lib.rs");
assert!(SRC.contains("pub sas_verified: bool,"), "the field must be exposed");

// not flagged
const SRC: &str = include_str!("lib.rs");
let prod = SRC.split_once("\n#[cfg(test)]\nmod tests {").expect("test module").0;
assert!(prod.contains("InviterSecrets::create_for_group("), "production never calls it");

Beide betten den eigenen Quellcode der Datei ein. Der erste testet direkt auf SRC – und SRC enthält den Test selbst, einschließlich des genau gesuchten Strings. Er ist konstruktionsbedingt wahr: Löscht man den Produktionscode, den er angeblich schützt, bleibt er grün. Der zweite schneidet zuerst das Testmodul ab und testet nur auf den Produktionsausschnitt, sodass er fehlschlägt, wenn sich der Produktionscode ändert. Das ist eine echte Absicherung.

Beim Scannen dieser Datei wird ein Treffer gemeldet, an der richtigen Zeile, und die anderen vier include_str!-Stellen bleiben unberührt. Der Scanner folgt der Bindung und nicht dem Mustervergleich auf include_str!, was die beiden Fälle unterscheidet.

Related MCP server: leakguard-mcp

Regeln

Sprachen

Die Rust- und JS-Scanner maskieren String-Literale und Kommentare, bevor sie abgleichen, sodass eine { in einem String oder eine auskommentierte Assertion sie nicht in die Irre führen kann. Sie sind darauf abgestimmt, einen Fall eher zu übersehen als zu erfinden: Ein falsch positiver Treffer kostet hier mehr als ein falsch negativer, denn die erste falsche Antwort lehrt die Leute, die Ausgabe zu ignorieren.

Behandeln Sie jeden Treffer als eine zu prüfende Frage, nicht als Urteil. Jeder nennt eine Datei und eine Zeile, sodass die Bestätigung Sekunden dauert.

Installation

Noch nicht auf PyPI – von der Quelle installieren:

git clone https://github.com/zegroged/vacuous-tests-mcp
cd vacuous-tests-mcp
pip install .

Das legt einen vacuous-tests-mcp-Befehl auf Ihren PATH.

Verwendung über einen MCP-Client

Fügen Sie Folgendes zur MCP-Konfiguration Ihres Clients hinzu:

{
  "mcpServers": {
    "vacuous-tests": {
      "command": "vacuous-tests-mcp"
    }
  }
}

Für Claude Code:

claude mcp add vacuous-tests -- vacuous-tests-mcp

Bitten Sie es dann, etwas zu scannen:

Scanne ./src nach Tests, die nicht fehlschlagen können.

Werkzeuge

scan_tests(path, include_skipped=True, max_findings=100) – Durchsucht eine Datei oder ein Verzeichnis und meldet Tests, die nicht fehlschlagen können. Build- und Abhängigkeitsverzeichnisse (target, node_modules, .venv, …) werden übersprungen. Die Ergebnisse kommen zuerst mit der höchsten Schwere, jeweils mit Pfad, Zeile, Testname, Regel und Ausschnitt.

list_rules() – Jede Regel mit einer Beschreibung, damit ein Modell entscheiden kann, wonach es fragen soll.

explain_rule(rule) – Was eine Regel erkennt und wie der Treffer normalerweise behoben wird.

Der Server liest nur. Er schreibt keine Dateien, führt den gescannten Code nicht aus und schaut nicht über den ihm gegebenen Pfad hinaus.

Entwicklung

pip install -e ".[dev]"
pytest

Die Suite deckt jede Regel in jeder Sprache ab und – was wichtiger ist – prüft, dass ein normaler Test neben einem inhaltslosen nicht gemeldet wird. Es gibt auch einen End-to-End-Test, der den Server als Unterprozess startet und ihn über einen echten MCP-Handshake steuert, sodass die Protokollebene abgedeckt und nicht nur angenommen wird.

Einschränkungen

• Die Erkennung von Rust und JS/TS ist textbasiert, keine Analyse. Makro-generierte Tests, ungewöhnliche Formatierung und stark verschachtelte Closures können übersehen werden.

• no-assertions weiß nicht, dass ein Test möglicherweise nur dazu dient, zu beweisen, dass etwas nicht in Panik gerät. Ein solcher Test ist nach der Regel ein echter Treffer und nach Absicht ein falscher; sagen Sie es mit einer expliziten Assertion, dann wird es ruhig.

• Es werden nur die oben genannten Sprachen gescannt. Andere Dateien werden ignoriert, nicht geraten.

Lizenz

MIT