Property testing y fuzzing: miles de entradas contra tus invariantes

Un test unitario clásico afirma un caso concreto: duplica(21) da 42. Es útil, pero comparte una debilidad con toda prueba basada en ejemplos: solo comprueba los casos que a ti se te ocurrieron, y los bugs viven precisamente en los que no se te ocurrieron —la cadena vacía, el i32::MIN, el vector de un millón de elementos, el UTF-8 mal formado—. El testing basado en propiedades invierte el planteamiento. En lugar de escribir entradas, escribes una ley que debe cumplirse para todas las entradas de un tipo, y la máquina genera cientos o miles de ellas intentando refutarte. Cuando lo consigue, hace algo aún más valioso que fallar: reduce el contraejemplo hasta su forma mínima. Y cuando quieres ir más lejos —lanzar millones de entradas guiadas por la cobertura contra tu parser o tu decodificador— entra el fuzzing con cargo-fuzz. Dos herramientas, una misma idea: dejar que la generación mecánica explore el espacio que tu imaginación no alcanza.

De ejemplos a propiedades

El salto conceptual es dejar de preguntar “¿qué da esta entrada?” y empezar a preguntar “¿qué es siempre cierto?”. Esas verdades universales son las propiedades. Los arquetipos que conviene reconocer:

• Ida y vuelta (roundtrip): decodificar lo que se codificó devuelve el original. parsear(serializar(x)) == x.
• Idempotencia: aplicar dos veces es como aplicar una. normaliza(normaliza(x)) == normaliza(x).
• Oráculo: una implementación rápida coincide con una lenta pero obviamente correcta.
• Invariante preservada: una operación mantiene una propiedad estructural —ordenar no cambia la longitud ni el multiconjunto de elementos.

Con proptest, una propiedad se expresa dentro de la macro proptest!, declarando el tipo de las entradas que quieres que genere:

use proptest::prelude::*;

proptest! {
    #[test]
    fn ordenar_conserva_longitud(mut v in prop::collection::vec(any::<i32>(), 0..100)) {
        let n = v.len();
        v.sort();
        prop_assert_eq!(v.len(), n);
    }
}

El fragmento v in prop::collection::vec(any::<i32>(), 0..100) es una estrategia: describe cómo fabricar valores —un vector de entre cero y cien enteros cualesquiera—. proptest ejecutará el cuerpo cientos de veces con vectores distintos, y prop_assert_eq! es la aserción que, al romperse, dispara la búsqueda del mínimo.

Reducción: del caos al contraejemplo mínimo

La reducción (shrinking) es lo que separa una herramienta de propiedades de un simple generador aleatorio. Imagina una propiedad falsa que se rompe con un vector de ochenta números enormes. Sin reducción, verías esos ochenta números y no sabrías cuál importa. Con ella, al hallar un fallo, proptest simplifica la entrada sistemáticamente —acortando el vector, acercando los números a cero— y reejecuta, quedándose con la versión más pequeña que sigue fallando:

proptest! {
    #[test]
    fn suma_nunca_desborda(a in any::<i32>(), b in any::<i32>()) {
        let _ = a + b;   // fallara y se reducira hacia a=1, b=i32::MAX o similar
    }
}

El contraejemplo mínimo suele señalar la causa con el dedo: aquí, el desbordamiento aritmético en el límite del i32. Además, proptest guarda la semilla que provocó el fallo en un fichero proptest-regressions/; ese caso se reejecuta en cada corrida futura, de modo que un bug encontrado una vez no vuelve a esconderse.

quickcheck, la alternativa histórica inspirada en Haskell, persigue lo mismo con otra ergonomía: en lugar de estrategias explícitas, se apoya en el trait Arbitrary, que sabe generar y reducir valores de un tipo. Escribes una función que devuelve bool (o TestResult) y el tipo de sus argumentos elige el generador:

#[quickcheck]
fn invertir_dos_veces_es_identidad(xs: Vec<u8>) -> bool {
    let mut doble = xs.clone();
    doble.reverse();
    doble.reverse();
    doble == xs
}

Fuzzing: millones de entradas guiadas por la cobertura

El testing de propiedades genera entradas estructuradas de un tipo. El fuzzing ataca la frontera más peligrosa —código que consume bytes crudos: parsers, decodificadores, deserializadores— con una estrategia distinta y brutal: generar millones de secuencias de bytes, mutándolas, y —el matiz decisivo— dejándose guiar por la cobertura. El fuzzer observa qué ramas del código activa cada entrada y evoluciona las que exploran territorio nuevo, penetrando así ramas que la aleatoriedad pura jamás alcanzaría.

En Rust, cargo-fuzz integra libFuzzer. Se instala y se define un objetivo:

cargo install cargo-fuzz
cargo fuzz init
cargo fuzz run mi_parser

// fuzz/fuzz_targets/mi_parser.rs
#![no_main]
use libfuzzer_sys::fuzz_target;

fuzz_target!(|data: &[u8]| {
    let _ = micrate::parsear(data);   // no debe entrar en panico ni provocar UB
});

Dos matices elevan el fuzzing de truco a disciplina. El primero es el corpus: libFuzzer mantiene un conjunto de entradas interesantes —las que descubrieron ramas nuevas— y lo reutiliza entre ejecuciones, de modo que cada sesión parte del conocimiento acumulado por las anteriores en vez de empezar de cero. El segundo es la continuidad: un fuzzer no es una prueba que pasa o falla una vez, sino un proceso que cuanto más corre, más profundo cava. Proyectos críticos lo integran en servicios como OSS-Fuzz, que lo ejecutan sin descanso durante días y reportan cada hallazgo con su entrada mínima reproducible.

La macro fuzz_target! recibe un &[u8] que libFuzzer muta sin descanso. El fuzzer declara victoria cuando encuentra una entrada que provoca un pánico, un desbordamiento detectado, un fallo de aserción o —crucial en código unsafe— comportamiento indefinido cazado por los sanitizers. Si tu objetivo, en vez de bytes crudos, necesita datos con forma, el crate arbitrary traduce el flujo de bytes en tipos estructurados vía el trait Arbitrary, tendiendo un puente entre el fuzzing y las entradas tipadas del testing de propiedades.

flowchart TD
L[Escribes una ley que vale para toda entrada] --> G[proptest genera cientos de entradas tipadas]
G --> H{Alguna refuta la ley}
H -->|no| OK[Propiedad se sostiene esta corrida]
H -->|si| S[Reduce el contraejemplo al minimo]
S --> R[Guarda la semilla en proptest-regressions]
B[Superficie que consume bytes crudos] --> F[cargo-fuzz con libFuzzer muta millones de entradas]
F --> COV[Guiado por cobertura penetra ramas nuevas]
COV --> UB[Caza panicos desbordamientos y comportamiento indefinido]
style L fill:#cba6f7,color:#11111b
style S fill:#a6e3a1,color:#11111b
style F fill:#89b4fa,color:#11111b
style UB fill:#f38ba8,color:#11111b