vacuous-tests-mcp

Un servidor MCP que encuentra pruebas que pasan sin importar lo que haga el código.

Una prueba vacua es peor que una que falta. Una prueba que falta es visiblemente ausente. Una prueba vacua se sienta en la suite, se ejecuta en verde, cuenta en el total y se cita como evidencia de que un comportamiento está cubierto — mientras no comprueba nada. Es cobertura que está invisiblemente ausente, y sobrevive exactamente a las situaciones para las que existen las pruebas.

Son fáciles de escribir por accidente y difíciles de detectar leyendo, porque una prueba vacua y una real a menudo se ven casi idénticas.

El caso del que surgió esto

Un archivo Rust, de 6,764 líneas, en un proyecto cuya suite de pruebas ya estaba bajo auditoría manual regular. Dos pruebas en él:

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

Ambas incrustan el código fuente del propio archivo. La primera afirma directamente sobre SRC — y SRC contiene la prueba en sí, incluida la cadena que se busca. Es verdadera por construcción: elimina el código de producción que dice proteger y sigue en verde. La segunda corta primero el módulo de prueba y afirma solo sobre la porción de producción, por lo que falla cuando el código de producción cambia. Esa es una barrera real.

Escanear ese archivo informa un hallazgo, en la línea correcta, y deja los otros cuatro sitios de include_str! en paz. El escáner sigue el enlace en lugar de hacer coincidencia de patrones en include_str!, que es lo que separa los dos casos.

Related MCP server: leakguard-mcp

Reglas

Lenguajes

Los escáneres de Rust y JS enmascaran literales de cadena y comentarios antes de coincidir, por lo que una { dentro de una cadena o una afirmación comentada no puede engañarlos. Están ajustados para omitir un caso en lugar de inventar uno: un falso positivo cuesta más que un falso negativo aquí, porque la primera respuesta incorrecta enseña a la gente a ignorar la salida.

Trata cada hallazgo como una pregunta a comprobar, no como un veredicto. Cada uno nombra un archivo y una línea, por lo que confirmarlo lleva segundos.

Instalación

Aún no está en PyPI — instala desde el código fuente:

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

Eso pone un comando vacuous-tests-mcp en tu PATH.

Úsalo desde un cliente MCP

Añade a la configuración MCP de tu cliente:

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

Para Claude Code:

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

Luego pídele que escanee algo:

Escanea ./src en busca de pruebas que no puedan fallar.

Herramientas

scan_tests(path, include_skipped=True, max_findings=100) Recorre un archivo o directorio e informa de pruebas que no pueden fallar. Los directorios de compilación y dependencias (target, node_modules, .venv, …) se omiten. Los hallazgos vuelven primero por mayor severidad, cada uno con una ruta, línea, nombre de prueba, regla y fragmento.

list_rules() Cada regla con una descripción, para que un modelo pueda decidir qué pedir.

explain_rule(rule) Qué detecta una regla y cómo se resuelve normalmente el hallazgo.

El servidor solo lee. No escribe archivos, no ejecuta el código que escanea y no mira fuera de la ruta que se le da.

Desarrollo

pip install -e ".[dev]"
pytest

La suite cubre cada regla en cada lenguaje y — lo más importante — comprueba que una prueba normal situada junto a una vacua no se informe. También hay una prueba de extremo a extremo que inicia el servidor como subproceso y lo conduce a través de un apretón de manos MCP real, por lo que la capa de protocolo está cubierta en lugar de asumida.

Limitaciones

• La detección de Rust y JS/TS es textual, no un análisis sintáctico. Las pruebas generadas por macros, el formato inusual y los cierres muy anidados pueden pasarse por alto.

• no-assertions no sabe que una prueba puede existir puramente para demostrar que algo no entra en pánico. Tal prueba es un verdadero positivo según la regla y un falso positivo por intención; dilo con una afirmación explícita y se callará.

• Solo se escanean los lenguajes de la tabla anterior. Otros archivos se ignoran, no se adivinan.

Licencia

MIT