vacuous-tests-mcp

코드가 무엇을 하든 통과하는 테스트를 찾는 MCP 서버입니다.

공허한 테스트는 없는 테스트보다 더 나쁩니다. 없는 테스트는 눈에 띄게 없습니다. 공허한 테스트는 스위트에 자리 잡고, 초록불이 켜지고, 총계에 포함되며, 어떤 동작이 커버된다는 증거로 인용되지만, 아무것도 검사하지 않습니다. 그것은 보이지 않게 부재한 커버리지이며, 테스트가 잡아내기 위해 존재하는 바로 그 상황에서 살아남습니다.

그것들은 실수로 작성하기 쉽고 읽어서 발견하기 어렵습니다. 공허한 테스트와 실제 테스트는 종종 거의 동일해 보이기 때문입니다.

이 도구가 만들어진 사례

6,764줄짜리 Rust 파일이 있는 프로젝트에서, 그 테스트 스위트는 이미 정기적인 수동 감사 대상이었습니다. 그 안에 두 개의 테스트가 있습니다:

// 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에는 검색 대상 문자열을 포함한 테스트 자체가 들어 있습니다. 구조적으로 참입니다. 보호한다고 주장하는 프로덕션 코드를 삭제해도 여전히 초록불입니다. 두 번째는 먼저 테스트 모듈을 잘라내고 프로덕션 부분에 대해서만 단언하므로, 프로덕션 코드가 변경되면 실패합니다. 그것이 진짜 게이트입니다.

그 파일을 스캔하면 올바른 줄에서 하나의 발견을 보고하고, 나머지 네 개의 include_str! 위치는 건드리지 않습니다. 스캐너는 include_str!에 대한 패턴 매칭 대신 바인딩을 추적하는데, 이것이 두 경우를 구분하는 요소입니다.

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) 하나의 규칙이 무엇을 감지하는지와 발견이 일반적으로 어떻게 해결되는지 설명합니다.

서버는 읽기만 합니다. 파일을 쓰지 않고, 스캔하는 코드를 실행하지 않으며, 주어진 경로 밖을 보지 않습니다.

개발

pip install -e ".[dev]"
pytest

스위트는 각 언어의 각 규칙을 다루며, 더 중요한 것은 공허한 테스트 옆에 있는 정상적인 테스트가 보고되지 않는지 확인합니다. 또한 서버를 하위 프로세스로 시작하고 실제 MCP 핸드셰이크를 통해 구동하는 엔드투엔드 테스트도 있어, 프로토콜 계층이 가정이 아니라 검증됩니다.

제한 사항

• Rust 및 JS/TS 감지는 텍스트 기반이며 파싱이 아닙니다. 매크로로 생성된 테스트, 비정상적인 포맷, 깊게 중첩된 클로저는 놓칠 수 있습니다.

• no-assertions는 테스트가 순전히 무언가가 패닉하지 않음을 증명하기 위해 존재할 수 있다는 것을 알지 못합니다. 그러한 테스트는 규칙상 진양성이고 의도상 거짓 양성입니다. 명시적인 단언으로 그렇게 말하면 조용해집니다.

• 위 표의 언어만 스캔됩니다. 다른 파일은 무시되며 추측하지 않습니다.

라이선스

MIT