vacuous-tests-mcp

コードが何をしても通るテストを見つけるMCPサーバーです。

空虚なテストは、テストがないことよりも悪いです。テストがないことは目に見えてわかります。しかし、空虚なテストはスイートの中に存在し、グリーンで実行され、合計に数えられ、動作がカバーされている証拠として引用されます。実際には何もチェックしていないのにです。それは、目に見えない形で欠けているカバレッジであり、テストが存在するまさにその状況を生き延びます。

これらは偶然書いてしまいやすく、読んで見つけるのは難しいです。なぜなら、空虚なテストと本物のテストはしばしばほぼ同じに見えるからです。

このケースが作られた背景

6,764行のRustファイルがあり、そのプロジェクトのテストスイートはすでに定期的な手動監査の対象でした。その中の2つのテスト：

// 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");

どちらもファイル自身のソースを埋め込んでいます。最初のテストはSRCに対して直接アサートしています。そしてSRCにはテスト自体が含まれており、検索対象の文字列そのものも含まれています。これは構造的に真です。主張している本番コードを削除しても、グリーンのままです。2番目のテストは、まずテストモジュールを切り離し、本番スライスのみに対してアサートするため、本番コードが変更されると失敗します。こちらは本物のゲートです。

そのファイルをスキャンすると、1件の検出が正しい行に報告され、他の4つのinclude_str!サイトはそのまま残ります。スキャナーはinclude_str!をパターンマッチングするのではなく、バインディングを追跡するため、2つのケースを区別できます。

Related MCP server: leakguard-mcp

ルール

言語

RustとJSのスキャナーは、マッチングの前に文字列リテラルとコメントをマスクするため、文字列内の{やコメントアウトされたアサーションが誤解を招くことはありません。これらは、ケースを見逃すように調整されており、作り出すことはありません。ここでは、誤検知は誤検知よりもコストがかかります。最初の間違った回答が、人々に出力を無視することを教えるからです。

すべての検出結果は、判定ではなく確認すべき質問として扱ってください。それぞれがファイルと行を指定しているため、確認には数秒しかかかりません。

インストール

まだPyPIにはありません — ソースからインストールしてください：

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

これでvacuous-tests-mcpコマンドがPATHに追加されます。

MCPクライアントから使用する

クライアントのMCP設定に追加します：

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

Claude Codeの場合：

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

次に、スキャンを依頼します：

./src をスキャンして、失敗できないテストを探してください。

ツール

scan_tests(path, include_skipped=True, max_findings=100) ファイルまたはディレクトリを走査し、失敗できないテストを報告します。ビルドおよび依存関係ディレクトリ（target、node_modules、.venvなど）はスキップされます。検出結果は重大度の高い順に返され、それぞれにパス、行、テスト名、ルール、スニペットが含まれます。

list_rules() 説明付きのすべてのルール。モデルが何を要求するかを決定できるようにします。

explain_rule(rule) 1つのルールが何を検出し、検出結果が通常どのように解決されるか。

サーバーは読み取りのみを行います。ファイルを書き込まず、スキャンするコードを実行せず、指定されたパスの外を見ることはありません。

開発

pip install -e ".[dev]"
pytest

スイートは各言語の各ルールをカバーし、さらに重要なことに、空虚なテストの隣にある通常のテストが報告されないことをチェックします。また、サーバーをサブプロセスとして起動し、実際のMCPハンドシェイクを通じて駆動するエンドツーエンドテストもあります。これにより、プロトコル層が想定ではなくカバーされます。

制限事項

• RustおよびJS/TSの検出はテキストベースであり、パースではありません。マクロ生成テスト、異常なフォーマット、深くネストされたクロージャは見逃される可能性があります。

• no-assertionsは、テストがパニックしないことを証明するためだけに存在する可能性があることを認識しません。そのようなテストは、ルール上は真陽性であり、意図上は偽陽性です。明示的なアサーションでそれを示せば、静かになります。

• 上記の表の言語のみがスキャンされます。他のファイルは無視され、推測されません。

ライセンス

MIT