Prueba Vacía.

Una prueba existe y se informa como aprobada, pero su cuerpo no tiene código ejecutable: sin preparación, sin ejercitación, sin aserción. Formas reveladoras:

// Cuerpo completamente vacío
test('calculates tax', () => {});

// Solo un comentario TODO / de marcador de posición
it('should reject invalid input', () => {
  // TODO: escribir esto cuando la API se estabilice
});

// Todo está comentado
it('parses the auth header', () => {
  // const result = parse(header);
  // expect(result).toEqual(expected);
});

Cómo detectarlo:

• El nombre de la prueba promete un comportamiento, pero el cuerpo es {}, espacios en blanco o solo comentarios.
• El resumen de tu ejecutor muestra la prueba como aprobada (verde), no omitida/pendiente; eso es lo que la hace peligrosa.
• La cobertura de código para la funcionalidad nombrada es sospechosamente cero aunque exista una "prueba para ella".
• Durante la revisión, el diff añade un caso de prueba pero ninguna llamada expect/assert.

Relacionado pero distinto: una prueba que tiene preparación y llama al sistema bajo prueba pero no hace ninguna aserción es el olor Prueba sin aserción / Prueba Desconocida. Una Prueba Vacía es el caso más extremo, donde el cuerpo carece por completo de sentencias.

Por qué ocurre

• Se generó el esqueleto de una prueba como marcador de posición (TDD "escribe primero el nombre") y nunca se completó.
• Se comentó código para depurar un fallo o silenciar una prueba inestable, y luego se confirmó y se olvidó.
• Un generador/IDE produjo un esqueleto de prueba que nadie completó.
• Un desarrollador quiso "reservar" un nombre de prueba para más adelante, pero usó un cuerpo vacío en lugar de un marcador todo explícito.

Por qué es perjudicial

• Falsa confianza (lo peor de todo). La mayoría de los ejecutores informan una prueba vacía como aprobada, no omitida. JUnit, Jest, Vitest y compañía mostrarán verde para test('x', () => {}). La suite parece cubrir el comportamiento, pero una regresión en el código de producción nunca se detectará, lo que podría decirse que es peor que no tener ninguna prueba, porque la marca verde induce activamente a error.
• Legibilidad. Un lector ve una prueba llamada should reject invalid input y supone razonablemente que ese comportamiento se verifica. El nombre documenta una intención que el cuerpo nunca cumple.
• Mantenibilidad. Las pruebas vacías inflan el recuento de pruebas y la percepción de cobertura por nombre, ocultando huecos reales y dificultando distinguir los marcadores de posición intencionales de los abandonados.
• Erosiona la confianza. Una vez que los colaboradores aprenden que "aprobada" no significa "verificada", la señal de toda la suite se debilita.

Decide si la prueba debe existir todavía y luego haz que el ejecutor diga la verdad.

1. Si el comportamiento debe probarse ahora, completa el cuerpo. Añade preparar/actuar/afirmar para que realmente ejercite el código:

// Antes — verde, pero no verifica nada
test('rounds half up', () => {});

// Después — expectativa real
test('rounds half up', () => {
  expect(round(2.5)).toBe(3);
});

2. Si es un marcador de posición genuino, márcalo explícitamente como pendiente para que el ejecutor lo informe como todo/omitido (visible, no falsamente verde) en lugar de dejar un cuerpo vacío. Un todo que cita su ticket de seguimiento es un marcador visible y honesto; un skip sin motivo ni ticket solo cambia este olor por un Ignored Test:

// Antes
it('should reject invalid input', () => {
  // TODO
});

// Después — aparece como todo en el informe, nunca como "aprobada"
it.todo('should reject invalid input (PROJ-123)');   // Jest / Vitest — cita el ticket de seguimiento
// test.skip(...) / xit(...) solo con un motivo explícito y un ticket; si no, es un Ignored Test

3. Si la prueba es obsoleta, elimínala. Una prueba eliminada es honesta; una vacía es una mentira que cuesta mantenimiento.

4. Restaura la lógica comentada. Si el cuerpo está completamente comentado, descoméntalo y corrígelo o elimina la prueba; nunca entregues código de prueba comentado como la "implementación".

5. Añade una salvaguarda. Activa una regla de linting de presencia de aserciones (ver detectores) en CI para que las pruebas vacías/sin aserción hagan fallar la compilación en lugar de pasar silenciosamente.