Tests unitarios: la prueba que vive junto al código

En casi todos los lenguajes el testing es un añadido: una librería que instalas, un corredor que configuras, una convención que el equipo pacta. En Rust es infraestructura del lenguaje. Una prueba es una función corriente marcada con #[test]; cargo test genera un ejecutable que las recolecta todas, las lanza en paralelo, captura su salida y te informa. Y hay una decisión de diseño que lo distingue de casi todo lo demás: las pruebas unitarias no viven en una carpeta aparte, sino junto al código que prueban, dentro de un módulo #[cfg(test)] mod tests. Esa vecindad no es descuido: es lo que les concede el privilegio de tocar lo privado, y lo que hace que se evaporen del binario que envías a producción. Entender ese módulo, el atributo #[test] y las aserciones es entender cómo Rust convierte la verificación en un ciudadano de primera.

Un test es una función anotada

El átomo del testing en Rust es una función sin argumentos ni retorno útil, marcada con #[test]. El arnés la considera aprobada si termina con normalidad y fallida si entra en pánico. Nada más:

pub fn suma(a: i32, b: i32) -> i32 {
    a + b
}

#[test]
fn suma_positivos() {
    assert_eq!(suma(2, 3), 5);
}

Cuando ejecutas cargo test, Cargo compila el crate en un modo especial, enlaza un main generado por el arnés de pruebas (el libtest estándar) y ese main invoca cada función #[test] que encuentra. Un pánico en cualquiera de ellas —un assert! roto, un unwrap sobre None— se atrapa en el límite de esa prueba y se traduce en un fallo, sin derribar a las demás.

Una prueba también puede devolver un Result, lo que permite usar el operador ? en su cuerpo y prescindir de una cascada de unwrap:

#[test]
fn parsea_configuracion() -> Result<(), std::num::ParseIntError> {
    let puerto: u16 = "8080".parse()?;
    assert_eq!(puerto, 8080);
    Ok(())
}

Aquí un Ok(()) es aprobación y un Err(_) es fallo. La regla es limpia: el Err viaja por ? y el arnés lo interpreta como prueba caída. La única renuncia es que una prueba que devuelve Result no puede combinarse con #[should_panic].

El módulo de tests: cfg(test) y el privilegio de lo privado

La convención canónica coloca las pruebas unitarias en un submódulo al final del propio fichero:

fn normaliza(x: f64) -> f64 {
    if x.is_nan() { 0.0 } else { x }
}

#[cfg(test)]
mod tests {
    use super::*;

    #[test]
    fn nan_se_vuelve_cero() {
        assert_eq!(normaliza(f64::NAN), 0.0);
    }
}

Dos piezas hacen el trabajo. El atributo #[cfg(test)] es compilación condicional: ese módulo entero solo existe cuando Cargo compila en modo prueba. En tu binario de release no queda ni rastro —ni el código de test, ni sus dependencias [dev-dependencies]—, de modo que verificar no engorda lo que envías. Y use super::* trae al alcance todo lo del módulo padre, incluido lo privado: como tests es un módulo hijo, normaliza le es visible aunque no sea pub. Ese es el argumento decisivo para que las pruebas unitarias vivan aquí y no fuera: son pruebas de caja blanca, escritas por quien conoce las tripas y quiere verificar detalles internos que la API pública jamás expone.

Conviene notar el reverso económico de #[cfg(test)]: como el módulo solo existe en modo prueba, sus dependencias exclusivas se declaran en la sección [dev-dependencies] del Cargo.toml, y tampoco viajan al binario final. Un generador de datos de prueba, una librería de aserciones más rica o un cronómetro de benchmarks pesan cero en producción. Verificar, en Rust, nunca engorda lo que envías.

Aserciones y el gobierno de cargo test

Las tres macros de aserción cubren casi todo: assert!(cond) exige que una condición sea cierta; assert_eq!(a, b) y assert_ne!(a, b) comparan e imprimen ambos operandos al fallar. Todas admiten un mensaje propio con la misma sintaxis de formato que println!, valiosísimo para contextualizar el fallo:

#[test]
fn saldo_no_negativo() {
    let saldo = calcular_saldo();
    assert!(saldo >= 0, "el saldo quedo negativo: {saldo}");
}

Para pruebas que deben entrar en pánico existe #[should_panic], y su forma precisa #[should_panic(expected = "...")] exige además que el mensaje del pánico contenga esa subcadena, evitando que la prueba pase por un pánico equivocado. Y #[ignore] aparca una prueba costosa para que no corra por defecto.

#[test]
#[should_panic(expected = "division por cero")]
fn divide_entre_cero_estalla() {
    dividir(10, 0);
}

Sobre la línea de comandos, cargo test es rico: ejecuta las pruebas en paralelo por defecto (ajustable con -- --test-threads=1 para forzar orden), captura la salida de las que aprueban y solo la muestra al fallar (o siempre con -- --nocapture), filtra por subcadena del nombre (cargo test saldo), la exige exacta con -- --exact, y corre las marcadas con #[ignore] mediante -- --ignored. El paralelismo por defecto no es un detalle: presiona a que cada prueba sea independiente, sin estado compartido ni orden implícito.

flowchart TD
C[cargo test] --> B[Compila el crate en modo prueba con cfg test activo]
B --> H[El arnes libtest genera un main que recolecta las funciones test]
H --> P[Ejecuta las pruebas en paralelo y captura su salida]
P --> OK[Termina con normalidad igual a aprobada]
P --> F[Entra en panico o devuelve Err igual a fallida]
style C fill:#cba6f7,color:#11111b
style H fill:#89b4fa,color:#11111b
style OK fill:#a6e3a1,color:#11111b
style F fill:#f38ba8,color:#11111b