Implementar Property-Based Testing

Descripción General

Los tests tradicionales basados en ejemplos verifican una entrada a la vez (assert reverse("abc") == "cba"). Los tests property-based describen propiedades universales (reverse(reverse(s)) == s) y el framework genera cientos de entradas aleatorias buscando violaciones. Este enfoque saca a la luz casos límite — strings vacíos, caracteres Unicode combinantes, overflow de enteros, nulos — que los ejemplos elegidos a mano raramente cubren.

Cuándo Usar

El property-based testing da resultado cuando la corrección se define por invariantes y no por salidas concretas. Para la teoría detrás del enfoque y una comparación de frameworks, consulta la guía completa de property-based testing.

• Funciones puras con propiedades matemáticas claras (ordenación, parsing, codificación, serialización)
• Rutinas de validación y sanitización de entrada que deben manejar datos arbitrarios
• Comportamiento de máquinas de estado donde las transiciones deben preservar invariantes
• Algoritmos que deben ser reversibles (compress/decompress, encrypt/decrypt, encode/decode)
• Has tenido bugs en producción causados por entradas de casos límite (colecciones vacías, MAX_INT, caracteres especiales)

Cuándo NO Usar

• El código depende mucho de I/O o tiene efectos secundarios — las propiedades son difíciles de enunciar y verificar
• Los tests deben comprobar el comportamiento exacto de escenarios de negocio concretos — usa tests basados en ejemplos
• La propiedad no puede enunciarse formalmente (“se ve bien para un humano”)
• El tiempo de ejecución importa — los property tests ejecutan cientos de iteraciones y pueden ser lentos

Cómo Funciona

Cada ejecución property-based es un bucle de tres etapas: generar, comprobar, reducir.

El generador saca entradas de una estrategia (st.text() en Hypothesis, fc.string() en fast-check, Arbitrary<String> en jqwik). Cuando la propiedad falla, el shrinker simplifica la entrada paso a paso hasta que ningún caso más pequeño sigue fallando — un array de 100 elementos se reduce a los tres que de verdad importan. El framework también imprime la seed de la ejecución aleatoria, así que cualquier fallo se puede repetir de forma determinista.

Implementación Paso a Paso

Python (Hypothesis)

import json
from hypothesis import given, strategies as st
from hypothesis.stateful import (
    RuleBasedStateMachine, rule, precondition, invariant,
)

# Propiedad básica: revertir dos veces devuelve el original
@given(st.text())
def test_reverse_is_involution(s):
    assert reverse(reverse(s)) == s

# Estrategia restringida
@given(st.integers(min_value=0, max_value=1000))
def test_square_is_non_negative(n):
    assert n * n >= 0

# Estrategia compuesta para objetos de dominio
@st.composite
def users(draw):
    return {
        "name": draw(st.text(min_size=1, max_size=100)),
        "age": draw(st.integers(min_value=0, max_value=150)),
        "email": draw(st.emails()),
    }

@given(users())
def test_user_serialization_roundtrip(user):
    assert json.loads(json.dumps(user)) == user

# Testing con estado: ejercita un stack y comprueba un invariante tras cada comando
class StackMachine(RuleBasedStateMachine):
    def __init__(self):
        super().__init__()
        self.items = []

    @rule(x=st.integers())
    def push(self, x):
        self.items.append(x)

    @precondition(lambda self: len(self.items) > 0)
    @rule()
    def pop(self):
        self.items.pop()

    @invariant()
    def size_is_never_negative(self):
        assert len(self.items) >= 0

TestStack = StackMachine.TestCase

JavaScript (fast-check)

import fc from 'fast-check';

// Propiedad: reverse(reverse(s)) === s
fc.assert(
  fc.property(fc.string(), (s) => {
    return reverse(reverse(s)) === s;
  }),
  { numRuns: 1000 }
);

// Propiedad: ordenar conserva la longitud y produce una lista monótona
fc.assert(
  fc.property(fc.array(fc.integer()), (arr) => {
    const sorted = arr.slice().sort((a, b) => a - b);
    for (let i = 1; i < sorted.length; i++) {
      if (sorted[i - 1] > sorted[i]) return false;
    }
    return sorted.length === arr.length;
  })
);

// Testing basado en modelo: los comandos implementan check() y run()
class ListModel {
  constructor() { this.items = []; }
  push(x) { this.items.push(x); }
  pop() { return this.items.pop(); }
  get length() { return this.items.length; }
}

class PushCommand {
  constructor(value) { this.value = value; }
  check() { return true; }
  run(model, real) {
    model.push(this.value);
    real.push(this.value);
  }
}

class PopCommand {
  check(model) { return model.length > 0; }
  run(model, real) {
    if (real.pop() !== model.pop()) {
      throw new Error('pop mismatch between model and implementation');
    }
  }
}

fc.assert(
  fc.property(
    fc.commands([
      fc.integer().map((n) => new PushCommand(n)),
      fc.constant(new PopCommand()),
    ]),
    (cmds) => {
      fc.modelRun(() => ({ model: new ListModel(), real: new MyList() }), cmds);
    }
  )
);

// Shrinking: fast-check reduce la entrada que falla al caso más pequeño
fc.assert(
  fc.property(fc.array(fc.integer()), (arr) => {
    return sum(arr) >= 0; // falla cuando los negativos generados suman menos que cero
  })
);

Java (jqwik)

import net.jqwik.api.*;
import net.jqwik.api.stateful.*;
import java.util.List;
import java.util.Stack;

class StringProperties {

    @Property
    boolean reverseOfReverseIsOriginal(@ForAll String s) {
        return reverse(reverse(s)).equals(s);
    }

    @Property
    boolean concatenationLengthIsSum(
        @ForAll @StringLength(min = 0, max = 100) String a,
        @ForAll @StringLength(min = 0, max = 100) String b
    ) {
        return (a + b).length() == a.length() + b.length();
    }

    @Property
    boolean sortedListIsOrdered(@ForAll List<@IntRange(min = -1000, max = 1000) Integer> numbers) {
        List<Integer> sorted = numbers.stream().sorted().toList();
        for (int i = 1; i < sorted.size(); i++) {
            if (sorted.get(i - 1) > sorted.get(i)) return false;
        }
        return true;
    }

    // Arbitraries personalizados (generadores)
    @Provide
    Arbitrary<Email> validEmails() {
        return Combinators.combine(
            Arbitraries.strings().alpha().ofLength(5),
            Arbitraries.of("gmail.com", "yahoo.com", "example.com")
        ).as((local, domain) -> new Email(local + "@" + domain));
    }

    @Property
    boolean emailParsingRoundTrip(@ForAll("validEmails") Email email) {
        return Email.parse(email.toString()).equals(email);
    }
}

// Testing con estado usando ActionChain
class StackProperties {

    @Property
    void stackNeverCorrupts(@ForAll("stackActions") ActionChain<Stack<Integer>> chain) {
        chain.run();
    }

    @Provide
    ActionChainArbitrary<Stack<Integer>> stackActions() {
        return ActionChain.startWith(Stack::new)
            .withAction(pushActions())
            .withAction(new PopAction());
    }

    Arbitrary<Action<Stack<Integer>>> pushActions() {
        return Arbitraries.integers().between(-1000, 1000)
            .map(PushAction::new);
    }

    static class PushAction implements Action<Stack<Integer>> {
        private final int value;
        PushAction(int value) { this.value = value; }
        @Override
        public Stack<Integer> run(Stack<Integer> stack) {
            stack.push(value);
            return stack;
        }
    }

    static class PopAction implements Action<Stack<Integer>> {
        @Override
        public boolean precondition(Stack<Integer> stack) {
            return !stack.isEmpty();
        }
        @Override
        public Stack<Integer> run(Stack<Integer> stack) {
            stack.pop();
            return stack;
        }
    }
}

Lo que funciona

• Empieza por las propiedades, no por los generadores. Lo difícil del property-based testing es encontrar la propiedad correcta (encode(decode(x)) == x), no escribir el generador.
• Usa el shrinking a fondo. El valor del enfoque está en el caso de fallo mínimo, así que asegúrate de que el shrinking de tu framework esté activado y revisa su salida en lugar de depurar la entrada aleatoria cruda.
• Combínalo con tests basados en ejemplos. Las propiedades verifican invariantes; los ejemplos verifican escenarios de negocio concretos. Necesitas ambos.
• Mantén las propiedades puras. Una propiedad que escribe en una base de datos o lee la hora actual no es reproducible y no se puede reducir bien.
• Usa una seed determinista en CI. Los property tests son aleatorios por naturaleza; una seed hace que los fallos sean reproducibles entre ejecuciones.
• Restringe los generadores a datos realistas. Las entradas bien formadas llegan antes a los fallos significativos — consulta la receta de generación de datos de test para estrategias que codifican reglas de dominio.

Errores Comunes

• Testear la implementación, no la especificación. Escribir property: sort(arr) == mySortFunction(arr) es tautológico y no encuentra bugs. Una suite que no detecta fallos inyectados es decorativa — el mutation testing mide exactamente eso.
• Propiedades demasiado débiles. length(f(x)) >= 0 siempre es verdadero y no aporta nada. Las propiedades deben ser lo bastante fuertes para atrapar bugs reales.
• Ignorar la salida del shrinking. Un array de 100 elementos que falla es difícil de depurar; el array reducido de tres elementos es lo que deberías analizar.
• Generadores lentos o que no terminan. Generar estructuras recursivas sin límites de profundidad puede colgar la ejecución de tests.
• Propiedades flaky por estado global. Una propiedad que muta un contador a nivel de módulo falla de forma impredecible según el orden de ejecución.

Solución de Problemas

• La misma propiedad pasa y falla aleatoriamente: la función bajo test toca tiempo, aleatoriedad o estado compartido. Aísla el estado y fija la seed reportada antes de depurar.
• La generación se cuelga o va muy lenta: las estrategias recursivas o sin límite producen valores enormes. Limita la profundidad (st.recursive(..., max_leaves=10)), acota el tamaño de las colecciones y mide el tiempo de generación por separado del tiempo de aserción.
• Un fallo desaparece al reejecutar: la seed cambió entre ejecuciones. Copia la seed que Hypothesis imprime con @reproduce_failure, o pasa { seed } a fc.assert, y después escribe un test basado en ejemplos para la entrada reducida.
• El shrinking tarda más que la ejecución del test: las estrategias muy anidadas encarecen la reducción. Simplifica la estrategia o acota maxShrinks — un caso mínimo algo mayor sigue siendo útil.
• La suite es demasiado lenta para CI: baja max_examples, numRuns o tries en el perfil de CI y deja las ejecuciones completas para un job nocturno.

Lectura Adicional

• Documentación de Hypothesis: estrategias, testing con estado y replay de la base de ejemplos en Python.
• Documentación de fast-check: arbitraries, testing basado en modelo y shrinking en TypeScript/JavaScript.
• Guía de usuario de jqwik: propiedades, providers y testing con estado mediante ActionChain en la JVM.
• Guía completa de property-based testing: la versión extensa de esta receta con los trade-offs de diseño.
• Proyecto acompañante ejecutable: los ejemplos de esta receta como proyectos Python, JavaScript y Java ejecutables.