Respuesta.

Historia de la pregunta

Las pruebas de código son uno de los procesos más antiguos e importantes en la industria del desarrollo. Sin embargo, en muchos lenguajes, las bibliotecas de pruebas se proporcionan por separado, y la integración de las pruebas en el código principal puede ser poco clara o incómoda. En Rust, desde las primeras versiones, el lenguaje fue diseñado con soporte para pruebas modulares explícitas "fuera de la caja".

Problema

En muchos lenguajes tradicionales, las pruebas están separadas o requieren la configuración de marcos y compiladores específicos. Esto complica el desarrollo colaborativo, aumenta el riesgo de desincronización entre la lógica principal y las pruebas, y dificulta la realización de pruebas de integración y modulares.

Solución

Rust integra un sistema de pruebas directamente a nivel de lenguaje: el módulo #[cfg(test)], la directiva #[test] y la herramienta cargo test permiten crear, ejecutar y controlar las pruebas dentro del código fuente. Esto garantiza una conexión estrecha entre el código y las pruebas que lo verifican, asegurando la facilidad de ejecución de pruebas y la automatización de procesos de CI/CD.

Ejemplo de código:

// pruebas automáticamente compiladas y ejecutadas por `cargo test`
#[cfg(test)]
mod tests {
    use super::*;

    #[test]
    fn it_adds_two() {
        assert_eq!(2 + 2, 4);
    }
}

Características clave:

• Integración de pruebas: las pruebas se escriben en el mismo árbol de fuentes que la lógica principal, lo que facilita el mantenimiento.
• Facilidad de ejecución y gestión: un solo comando (cargo test) ejecuta todas las pruebas detectadas.
• Aislamiento de módulos probados: el uso de espacios de nombres y un atributo especial #[cfg(test)] permite no incluir pruebas en la compilación de lanzamiento.

Preguntas tramposas.

¿Se pueden usar funciones inestables o privadas en pruebas, y cómo se hace?

Sí, se puede. Dentro del módulo de pruebas, declarado como #[cfg(test)], las pruebas pueden ver no solo la API pública, sino también la privada del módulo actual. Esto significa que se pueden probar detalles de la implementación directamente. Sin embargo, desde otro módulo, solo a través de la interfaz pública.

Ejemplo:

fn private_internal(x: i32) -> i32 { x + 1 }

#[cfg(test)]
mod tests {
    use super::*;
    #[test]
    fn test_private() {
        assert_eq!(private_internal(41), 42);
    }
}

¿Los nombres de las pruebas idénticas confligirán entre diferentes módulos?

No, los nombres de las pruebas son visibles solo dentro de su propio módulo. Las pruebas de diferentes módulos pueden tener el mismo nombre porque el compilador las distingue por su ruta completa (namespace).

Ejemplo:

mod a {
    #[cfg(test)]
    mod tests {
        #[test]
        fn basic() {}
    }
}
mod b {
    #[cfg(test)]
    mod tests {
        #[test]
        fn basic() {}
    }
}

¿Se puede ejecutar una prueba individual o una parte de un conjunto de pruebas?

Sí, mediante la filtración del nombre de la prueba: cargo test nombre_de_prueba. Esto es conveniente para depurar grandes conjuntos.

Ejemplo:

cargo test only_this_test

Errores típicos y anti-patrón

• Escribir pruebas largas y no atómicas que verifiquen varios aspectos de la función a la vez.
• Comentar o eliminar inmediatamente las pruebas que comienzan a "fallar" con cambios en el código, en lugar de buscar y corregir la causa.
• Dependencia de la prueba del estado global: realizar acciones no limpias o no reversibles (por ejemplo, crear archivos que no se eliminan).

Ejemplo de la vida real

Caso negativo

Un desarrollador trasladó las pruebas a un proyecto separado sin acceso a funciones privadas y con otra estructura de directorios. Debido a cambios en la biblioteca principal, las pruebas comenzaron a quedarse rápidamente desactualizadas y perder relevancia.

Ventajas: Se puede aislar la prueba, evitar que los módulos de prueba se incluyan accidentalmente en la compilación de lanzamiento.

Desventajas: Pérdida de sincronicidad, imposibilidad de probar detalles internos, alta mantenibilidad y riesgo de desactualización de las pruebas.

Caso positivo

Las pruebas se escriben directamente en los mismos módulos que la lógica principal, pequeños casos de prueba atómicos prueban tanto la API privada como la pública. Un principiante puede comprender rápidamente el funcionamiento del módulo a través de las pruebas.

Ventajas: Máxima sincronización de apoyo, transparencia, prueba local acelerada, idoneidad para desarrollo impulsado por pruebas.

Desventajas: Aumento del número de líneas de código en los archivos fuente, posible aumento de la complejidad con un gran número de pruebas.