---
title: "Prueba Vacía"
type: "test-smell"
slug: "empty-test"
url: "http://localhost:3000/es/test-smells/empty-test.md"
category: "Olores prescindibles"
description: "Una Prueba Vacía es un método de prueba cuyo cuerpo no contiene sentencias ejecutables, por lo que siempre pasa sin verificar nada."
---
# Prueba Vacía

> Una Prueba Vacía es un método de prueba cuyo cuerpo no contiene sentencias ejecutables, por lo que siempre pasa sin verificar nada.

## Signs and Symptoms

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:

```js
// 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.

## Reasons for the Problem

**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.

## Treatment

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:

```js
// 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:

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

// Después — aparece como todo en el informe, nunca como "aprobada"
it.todo('should reject invalid input');   // Jest / Vitest
// o test.skip(...) / xit(...) con un ticket de seguimiento

```

**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.

## Detected by

- **eslint-jest** `expect-expect` — eslint-plugin-jest: expect-expect (marca pruebas sin aserción, incluidos los cuerpos vacíos) (https://github.com/jest-community/eslint-plugin-jest/blob/main/docs/rules/expect-expect.md)
- **eslint-vitest** `expect-expect` — eslint-plugin-vitest: expect-expect (exige al menos una expectativa por prueba) (https://github.com/vitest-dev/eslint-plugin-vitest/blob/main/docs/rules/expect-expect.md)
- **eslint** `no-empty-function` — ESLint core: no-empty-function (regla general; marca el cuerpo vacío de función/flecha de un callback de prueba vacío) (https://eslint.org/docs/latest/rules/no-empty-function)
- **sonar** `S2699` — SonarSource: S2699 "Las pruebas deben incluir aserciones" (Bloqueante; marca pruebas sin aserción y vacías; existen equivalentes para Java/C#/Python) (https://rules.sonarsource.com/javascript/RSPEC-2699/)
- **pmd** `JUnitTestsShouldIncludeAssert` — PMD (Java): JUnitTestsShouldIncludeAssert (marca pruebas JUnit que carecen de aserción, incluidas las pruebas vacías) (https://pmd.github.io/pmd/pmd_rules_java_bestpractices.html#junittestsshouldincludeassert)