¿Cómo se reproduce deterministamente un fallo de Property-Based Testing reportado en CI?

fast-check imprime en los registros de error los parámetros exactos: `seed` y `path`. Para reproducir el fallo en local, se pasan dichos valores a las opciones de `fc.assert(property, { seed, path })`. El generador recreará la secuencia pseudoaleatoria exacta y fallará en la primera ejecución.

¿Cuándo son preferibles los tests parametrizados (test.each) sobre Property-Based Testing?

test.each es idóneo ante especificaciones discretas y regulatorias: códigos de estado HTTP asociados a tipos de error, tablas impositivas fijas o diccionarios de internacionalización. PBT es superior al probar funciones algorítmicas, parsers, codecs y estructuras de datos con dominios de entrada continuos.

¿Cómo se integra fast-check con operaciones asíncronas y llamadas de red?

Empleando `fc.asyncProperty` en lugar de `fc.property` y esperando la ejecución con `await fc.assert(...)`. Esto garantiza que fast-check espere la resolución de promesas y microtareas en cada iteración antes de proceder a la siguiente generación aleatoria.

¿Cuál es la principal limitación de las pruebas basadas en ejemplos y cómo la supera el enfoque Property-Based?

Las pruebas basadas en ejemplos examinan únicamente puntos discretos en un espacio infinito de entradas, sesgados por las asunciones del autor. Property-Based Testing genera cientos de combinaciones pseudoaleatorias con casos límite extremos (caracteres de control, Unicode corrupto, desbordamiento aritmético) y comprueba el cumplimiento de leyes matemáticas universales en vez de coincidencias escalares.

¿Cómo opera el mecanismo de Shrinking en la librería fast-check?

Cuando se detecta una entrada que quebranta una propiedad, fast-check activa un algoritmo de reducción binaria. Para números, reduce hacia cero; para arrays, recorta su longitud y minimiza los elementos individuales; para cadenas, purga caracteres y los simplifica a códigos ASCII elementales. Esto aísla el contraejemplo mínimo necesario para identificar la causa raíz.

¿Por qué el antipatrón del oráculo (Oracle Anti-pattern) resulta peligroso en fast-check?

Porque el desarrollador duplica la lógica interna de la función dentro del bloque de aserción. Si la función presenta un error conceptual, el oráculo duplicado replicará la misma falla y la prueba pasará falsamente en verde. La prueba debe evaluar propiedades observables externas y no espejar la implementación.

¿Cuáles son los patrones de invariantes más utilizados en aplicaciones reales?

1) Roundtrip (parse(serialize(x)) === x); 2) Idempotence (f(f(x)) === f(x)); 3) Invariance (preservación de longitudes o invariantes estructurales); 4) Metamorphic Relations (cambios predecibles en la salida ante alteraciones controladas en la entrada); 5) Test Oracle (contrastar un algoritmo optimizado frente a una implementación de referencia ingenua pero indudablemente correcta).

Property-Based Testing y Fuzzing con fast-check — Pruebas y Automatización QA

Modelo mental#

Las pruebas tradicionales basadas en ejemplos (Example-Based Testing) adolecen del sesgo de confirmación (Confirmation Bias): el ingeniero tiende a verificar únicamente los casos frontera que anticipó durante el diseño del código. En consecuencia, anomalías críticas —arrays vacíos, pares suplentes de Unicode, cero negativo (-0), NaN, pérdida de precisión numérica o caracteres de control— terminan alcanzando producción inadvertidamente.

El enfoque Property-Based Testing (PBT) revoluciona este paradigma. El desarrollador establece:

Generadores de datos (Arbitrary): Declaraciones que acotan el universo de entradas válidas (fc.string(), fc.integer(), fc.record()).
Invariantes (Properties): Reglas universales que deben cumplirse para cualquier entrada generada (por ejemplo: reverse(reverse(list)) === list).
Mecanismo de reducción (Shrinking): Proceso que reduce un payload fallido complejo (por ejemplo, una cadena de 10.000 caracteres) a un valor atómico conciso (como un byte nulo \0 o el valor -101).

text

+-------------------------------------------------------------------------+
|                  Property-Based Testing Loop (fast-check)               |
+-------------------------------------------------------------------------+
                                     |
                                     v
                  +-------------------------------------+
                  |   Arbitrary Generator (100+ runs)   |
                  |   fc.record({ id: fc.uuid(), ... }) |
                  +-------------------------------------+
                                     |
                                     v
                  +-------------------------------------+
                  |        Execute Invariant Test       |
                  |     assert(isInvariantHold(x))      |
                  +-------------------------------------+
                                     |
                     +---------------+---------------+
                     |                               |
             [Todas las pruebas pasan]        [La prueba falla]
                     |                               |
                     v                               v
            +-----------------+             +-----------------+
            |   PASSED (100)  |             |  SHRINKING LOOP |
            +-----------------+             | Reducción input |
                                            +-----------------+
                                                     |
                                                     v
                                            +-----------------+
                                            | Min Counter-ex: |
                                            | e.g. input: ""  |
                                            +-----------------+

Example-Based Testing (test.each) vs Property-Based Testing (fast-check)

Критерий	test.each (Ejemplos Estáticos)	fast-check (Property-Based)
Muestreo de entrada	Lista estática de 3 a 5 valores diseñados a mano	Cientos de combinaciones pseudoaleatorias con sesgo a casos límite
Cobertura de fronteras	Estrictamente supeditada a la imaginación del autor	Fuzzing automático sobre Unicode, -Infinity, NaN y caracteres nulos
Objetivo de la aserción	Equivalencia escalar fija (result === expected)	Invariante sistémico universal (Roundtrip, Idempotence, Invariance)
Aislamiento del defecto	Muestra únicamente el fixture rígido codificado en el array	El Shrinking aísla el contraejemplo mínimo que causa la rotura

Casos de uso prácticos#

Pruebas de parsers y serializadores (Roundtrip Property): Garantizar que cualquier estado transformado a texto (JSON, URL Query, Protobuf) y parseado nuevamente recupera el objeto idéntico: parse(serialize(x)) === x.
Comprobación de idempotencia en transformaciones (Idempotence Property): Verificar que aplicar rutinas de sanitización o normalización repetidamente preserva el resultado previo: clean(clean(x)) === clean(x).
Invariantes en precios y carritos de compra: Demostrar matemáticamente que la aplicación de descuentos nunca produce costes negativos ni excede el valor base: 0 <= applyDiscount(price, rate) <= price.
Fuzzing de esquemas de validación en tiempo de ejecución (Zod, ArkType): Demostrar que los esquemas resisten entradas malformadas, prototipos circulares y cargas extremas sin arrojar excepciones no controladas (No-Crash Invariant).

Cómo funciona#

1. El patrón Roundtrip: serializador de parámetros URL#

El principio de reversibilidad Roundtrip establece que codificar y decodificar consecutivamente una estructura restaura el estado original sin pérdidas de datos.

typescriptsrc/shared/url/queryParams.test.ts

import { describe, it, expect } from 'vitest';
import fc from 'fast-check';

export interface QueryState {
  filter: string;
  page: number;
  isActive: boolean;
}

export function serializeQuery(state: QueryState): string {
  const params = new URLSearchParams();
  params.set('filter', state.filter);
  params.set('page', state.page.toString());
  params.set('isActive', state.isActive ? '1' : '0');
  return params.toString();
}

export function parseQuery(queryString: string): QueryState {
  const params = new URLSearchParams(queryString);
  const filter = params.get('filter') ?? '';
  const pageRaw = parseInt(params.get('page') ?? '1', 10);
  const page = Number.isNaN(pageRaw) ? 1 : pageRaw;
  const isActive = params.get('isActive') === '1';

  return { filter, page, isActive };
}

describe('Roundtrip: serializeQuery <-> parseQuery', () => {
  it('garantiza la restauración exacta del estado tras codificar y decodificar', () => {
    // Generador Arbitrary para modelar instancias válidas de QueryState
    const queryArbitrary = fc.record<QueryState>({
      // Cadenas arbitrarias con espacios, caracteres Unicode y símbolos URI
      filter: fc.string(),
      // Rango natural de paginación entre 1 y 1.000.000
      page: fc.integer({ min: 1, max: 1_000_000 }),
      isActive: fc.boolean(),
    });

    fc.assert(
      fc.property(queryArbitrary, (originalState) => {
        const serialized = serializeQuery(originalState);
        const parsed = parseQuery(serialized);

        // Invariante: el objeto decodificado es idéntico al estado original
        expect(parsed).toEqual(originalState);
      }),
      { numRuns: 200 } // Evaluar 200 combinaciones aleatorias generadas
    );
  });
});

2. El patrón Idempotence: normalización idempotente de cadenas#

Una transformación (como el recorte de espacios y la canonización Unicode) debe ser idempotente: procesarla sobre un resultado ya transformado debe producir exactamente el mismo valor.

typescriptsrc/shared/text/normalizeSearchQuery.test.ts

import { describe, it, expect } from 'vitest';
import fc from 'fast-check';

export function normalizeSearchQuery(input: string): string {
  return input
    .normalize('NFKC')
    .trim()
    .toLowerCase()
    .replace(/\s+/g, ' ');
}

describe('Idempotencia: normalizeSearchQuery', () => {
  it('mantiene la estabilidad ante ejecuciones sucesivas f(f(x)) === f(x)', () => {
    fc.assert(
      fc.property(fc.fullUnicodeString(), (rawInput) => {
        const firstPass = normalizeSearchQuery(rawInput);
        const secondPass = normalizeSearchQuery(firstPass);

        // Invariante de idempotencia
        expect(secondPass).toBe(firstPass);
      })
    );
  });
});

3. El mecanismo de Shrinking: cómo fast-check aísla la raíz del fallo#

Supongamos que un conversor monetario contiene un defecto sutil: ante cantidades negativas, introduce un guion duplicado cuando los centavos son menores que -100.

typescriptsrc/domain/finance/formatCurrency.test.ts

import { describe, it, expect } from 'vitest';
import fc from 'fast-check';

// Función con un error de frontera intencionado
export function formatCurrencyCents(cents: number): string {
  const isNegative = cents < 0;
  const absCents = Math.abs(cents);
  const dollars = Math.floor(absCents / 100);
  const remainder = absCents % 100;
  const formattedNumber = `${dollars}.${remainder.toString().padStart(2, '0')}`;

  // Defecto intencionado: doble signo menos cuando cents < -100
  if (cents < -100) {
    return `--$${formattedNumber}`;
  }

  return isNegative ? `-$${formattedNumber}` : `$${formattedNumber}`;
}

describe('formatCurrencyCents (Demostración de Shrinking)', () => {
  it('nunca emite más de un signo menos en la cadena resultante', () => {
    const property = fc.property(fc.integer(), (cents) => {
      const formatted = formatCurrencyCents(cents);
      const minusCount = (formatted.match(/-/g) ?? []).length;
      expect(minusCount).toBeLessThanOrEqual(1);
    });

    // fast-check detectará la anomalía y la reducirá al caso mínimo
    expect(() => fc.assert(property)).toThrowError();
  });
});

Al ejecutar esta prueba, fast-check puede fallar inicialmente con -89437283. Seguidamente inicia el Shrinking:

Evalúa -44718641 (falla).
Evalúa -1000 (falla).
Evalúa -101 (falla).
Evalúa -100 (pasa con éxito).

El reporte emitido señala con precisión milimétrica:

text

Property failed after 14 tests
{ seed: 1892847293, path: "13:0:2:1", endOnFailure: true }
Counterexample: [-101]
Shrunk 28 time(s)

El equipo de ingeniería puede identificar de inmediato la condición de rotura: exactamente el valor -101.

Errores comunes#

Ошибка: Antipatrón del oráculo redundante (Oracle Anti-pattern)

Reescribir la lógica de la función bajo prueba dentro de fc.property únicamente comprueba que dos implementaciones idénticas coinciden, en lugar de validar un invariante real.

typescript

// ❌ Antipatrón: el test duplica la lógica de la propia función
fc.assert(
  fc.property(fc.integer(), fc.integer(), (a, b) => {
    expect(add(a, b)).toBe(a + b); // Duplicación estéril de add(a, b)
  })
);

// ✅ Solución recomendada: validar propiedades matemáticas (conmutatividad, elemento neutro)
fc.assert(
  fc.property(fc.integer(), fc.integer(), (a, b) => {
    expect(add(a, b)).toBe(add(b, a)); // Conmutatividad: a + b === b + a
    expect(add(a, 0)).toBe(a);         // Elemento neutro: a + 0 === a
  })
);

Ошибка: Dominios de generación excesivamente amplios (fc.anything())

Emplear generadores desprovistos de restricciones de dominio provoca que la inmensa mayoría de entradas sean descartadas prematuramente por los guardianes de tipo.

typescript

// ❌ Error: pasar cualquier objeto arbitrario a un validador de correos
fc.assert(fc.property(fc.anything(), (input) => { ... }));

// ✅ Solución recomendada: generadores acotados a las reglas del dominio
const emailArbitrary = fc.emailAddress();
fc.assert(fc.property(emailArbitrary, (email) => { ... }));

Ошибка: Pérdida de la semilla (seed) en la reproducción en CI

Si una prueba falla aleatoriamente en el servidor de CI, ejecutarla en local puede arrojar éxito debido a una semilla distinta. Para reproducirla de forma determinista se debe suministrar el seed.

typescript

// ✅ Fijación de semilla para reproducir el caso exacto de los logs de CI
fc.assert(property, {
  seed: 1892847293, // Copiado directamente del reporte de fallo
});

Ошибка: Evaluación de invariantes asíncronos sin fc.asyncProperty

Al evaluar funciones asíncronas con el fc.property sincrónico convencional, el runner termina la ejecución antes de resolver las promesas, ignorando aserciones fallidas.

typescript

// ❌ Error: la propiedad síncrona no espera la resolución de promesas
fc.assert(
  fc.property(fc.string(), async (str) => {
    const res = await asyncParser(str);
    expect(res).toBeDefined(); // ¡Se ejecuta cuando el test ya ha terminado!
  })
);

// ✅ Solución recomendada: utilizar fc.asyncProperty
fc.assert(
  fc.asyncProperty(fc.string(), async (str) => {
    const res = await asyncParser(str);
    expect(res).toBeDefined();
  })
);

Algoritmo de formulación de invariantes#

Metodología para adoptar Property-Based Testing

1. Identificación del invariante universalIdentify

Determinar la propiedad clave: Roundtrip (reversibilidad), Idempotence (estabilidad ante repetición) o Invariance (límites de magnitud o tipos).

2. Composición de ArbitrariesGenerate

Combinar generadores básicos (fc.string, fc.integer, fc.boolean) en modelos de dominio complejos con fc.record.

3. Ejecución con fast-check y VitestAssert

Ejecutar fc.assert(fc.property(...)) a lo largo de 100 a 500 iteraciones dentro de una suite estándar de Vitest.

4. Análisis de contraejemplos y ShrinkingFix

Al detectar un fallo, examinar el contraejemplo mínimo reducido e incorporarlo a la suite de regresión permanente.

Preguntas de entrevista#

Preguntas de entrevista7 preguntas

Temas relacionados#

Temas relacionados

Testing Trophy 2026: Pirámide vs. Trofeo de Pruebas— Distribución estratégica de pruebas e identificación de áreas candidatas a Property-Based Testing.Anatomía de un Test Limpio y Dobles de Prueba— Combinación de objetos Fake en memoria con estrategias de fuzzing.Pruebas de código asíncrono, temporizadores y fugas de memoria— Fuzzing sobre colas asíncronas y orquestación del Event Loop.