Respuesta.

Las pruebas unitarias en Rust están integradas en el propio lenguaje a través de macros integradas, atributos especiales e infraestructura de cargo. Históricamente, en C y otros lenguajes, las pruebas eran una extensión externa, lo que lleva a la discrepancia entre la interfaz del código de producción y las pruebas. En Rust, las pruebas se compilan y se ejecutan en el mismo entorno que el código principal, lo que elimina el problema de "funciona solo en pruebas".

Problema: las pruebas pueden ralentizar la compilación, ser poco informativas o estar mal organizadas; además, las pruebas mal aisladas dificultan el mantenimiento del código y su legibilidad.

Solución: las pruebas se escriben como funciones especiales marcadas con el atributo #[test] dentro del módulo mod tests. Todo el código de prueba se compila y se ejecuta solo con la clave cargo test, y se excluye de la compilación de producción. Se utilizan macros como assert_eq!, should_panic y métodos de configuración para aumentar la eficacia y la limpieza de las pruebas.

Ejemplo de código:

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

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

    #[test]
    fn test_add() {
        assert_eq!(add(2, 2), 4);
    }
}

Características clave:

Las pruebas se compilan solo al construir con cargo test, no entran en el binario de lanzamiento
Integración total en el lenguaje a través de atributos y macros
Organización fácil de las pruebas por módulos, pueden ser funciones de prueba públicas y privadas

Preguntas capciosas.

¿Es obligatorio colocar las pruebas solo en el módulo anidado mod tests?

No es obligatorio, pero se acepta para aislar las pruebas y prevenir traslapes del código de prueba en el lanzamiento. También ayuda a utilizar #[cfg(test)].

¿Se pueden ejecutar pruebas solo en un módulo/archivo específico?

Sí, se puede especificar el nombre de la prueba o su ruta usando cargo test nombre.

¿Se prueban las funciones privadas?

Sí, si el módulo de prueba se define en el mismo archivo y utiliza use super::*;, las pruebas tienen acceso a todas las funciones internas de ese archivo.

Errores comunes y anti-patrones

Falta de separación de los módulos de prueba del código (sin #[cfg(test)])
Duplicación de código o lógica compleja dentro de las pruebas
No utilizar assert_eq! o verificaciones sobrecomplicadas

Ejemplo de la vida real

Caso negativo

Las pruebas están mezcladas con el código principal, no están ocultas en #[cfg(test)], utilizan variables globales para la inicialización.

Ventajas:

Prototipado rápido

Desventajas:

El código de prueba entra en el lanzamiento
Las pruebas fallan debido a cambios en el código y no están aisladas

Caso positivo

Las pruebas están encapsuladas en módulos anidados, se utilizan funciones de configuración y macros assert_eq! para la verificación.