Communitygithub.com

patrones-de-pruebas-rust

Patrones de pruebas en Rust que incluyen pruebas unitarias, de integración, asíncronas, basadas en propiedades, mocking y cobertura. Sigue la metodología TDD. Úsalo al escribir pruebas en Rust (unitarias, de integración, asíncronas, basadas en propiedades o cobertura).

¿Qué es patrones-de-pruebas-rust?

Esta habilidad proporciona una guía completa y práctica sobre cómo escribir pruebas en Rust siguiendo la metodología TDD (Desarrollo Guiado por Pruebas). Es útil para cualquier desarrollador que quiera escribir código Rust más fiable y mantenible, cubriendo desde pruebas unitarias básicas hasta técnicas avanzadas como pruebas asíncronas, basadas en propiedades con proptest, mocking con mockall y benchmarks con Criterion. La habilidad explica el ciclo RED-GREEN-REFACTOR, la organización de pruebas unitarias y de integración, cómo probar errores y pánicos, y cómo medir la cobertura con cargo-llvm-cov. Está diseñada para ser utilizada tanto en proyectos pequeños como en sistemas complejos, integrando CI/CD con GitHub Actions y ofreciendo ejemplos de código directamente ejecutables. El enfoque principal es que las pruebas sirvan como documentación viva del código, mostrando cómo se espera que se use cada función o módulo.

Compatible con~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/affaan-m/everything-claude-code/tree/main/skills/rust-testing

Preguntar en tu IA favorita

Abre un nuevo chat con esta habilidad de agente ya precargada.

Documentación

Patrones de Pruebas en Rust

Patrones completos de pruebas en Rust para escribir pruebas fiables y mantenibles siguiendo la metodología TDD.

Cuándo Usar

  • Al escribir nuevas funciones, métodos o traits en Rust
  • Al añadir cobertura de pruebas a código existente
  • Al crear benchmarks para código crítico en rendimiento
  • Al implementar pruebas basadas en propiedades para validación de entrada
  • Al seguir el flujo de trabajo TDD en proyectos Rust

Cómo Funciona

  1. Identifica el código objetivo — Encuentra la función, trait o módulo a probar
  2. Escribe una prueba — Usa #[test] en un módulo #[cfg(test)], rstest para pruebas parametrizadas o proptest para pruebas basadas en propiedades
  3. Mockea las dependencias — Usa mockall para aislar la unidad bajo prueba
  4. Ejecuta las pruebas (RED) — Verifica que la prueba falla con el error esperado
  5. Implementa (GREEN) — Escribe el código mínimo para que pase
  6. Refactoriza — Mejora el código manteniendo las pruebas en verde
  7. Verifica la cobertura — Usa cargo-llvm-cov, apunta al 80%+

Flujo de Trabajo TDD para Rust

El Ciclo RED-GREEN-REFACTOR

RED     → Escribe una prueba que falla primero
GREEN   → Escribe el código mínimo para pasar la prueba
REFACTOR → Mejora el código mientras las pruebas se mantienen en verde
REPEAT  → Continúa con el siguiente requisito

TDD Paso a Paso en Rust

// RED: Escribe la prueba primero, usa todo!() como marcador
pub fn add(a: i32, b: i32) -> i32 { todo!() }

#[cfg(test)]
mod tests {
    use super::*;
    #[test]
    fn test_add() { assert_eq!(add(2, 3), 5); }
}
// cargo test → entra en pánico en 'not yet implemented'
// GREEN: Reemplaza todo!() con la implementación mínima
pub fn add(a: i32, b: i32) -> i32 { a + b }
// cargo test → PASA, luego REFACTORIZA manteniendo las pruebas en verde

Pruebas Unitarias

Organización de Pruebas a Nivel de Módulo

// src/user.rs
pub struct User {
    pub name: String,
    pub email: String,
}

impl User {
    pub fn new(name: impl Into<String>, email: impl Into<String>) -> Result<Self, String> {
        let email = email.into();
        if !email.contains('@') {
            return Err(format!("correo inválido: {email}"));
        }
        Ok(Self { name: name.into(), email })
    }

    pub fn display_name(&self) -> &str {
        &self.name
    }
}

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

    #[test]
    fn crea_usuario_con_correo_valido() {
        let user = User::new("Alice", "[email protected]").unwrap();
        assert_eq!(user.display_name(), "Alice");
        assert_eq!(user.email, "[email protected]");
    }

    #[test]
    fn rechaza_correo_invalido() {
        let result = User::new("Bob", "no-es-un-correo");
        assert!(result.is_err());
        assert!(result.unwrap_err().contains("correo inválido"));
    }
}

Macros de Aserción

assert_eq!(2 + 2, 4);                                    // Igualdad
assert_ne!(2 + 2, 5);                                    // Desigualdad
assert!(vec![1, 2, 3].contains(&2));                     // Booleano
assert_eq!(value, 42, "se esperaba 42 pero se obtuvo {value}");    // Mensaje personalizado
assert!((0.1_f64 + 0.2 - 0.3).abs() < f64::EPSILON);   // Comparación de flotantes

Pruebas de Errores y Pánicos

Probando Retornos Result

#[test]
fn parse_retorna_error_para_entrada_invalida() {
    let result = parse_config("}{invalid");
    assert!(result.is_err());

    // Afirma una variante de error específica
    let err = result.unwrap_err();
    assert!(matches!(err, ConfigError::ParseError(_)));
}

#[test]
fn parse_exitoso_para_entrada_valida() -> Result<(), Box<dyn std::error::Error>> {
    let config = parse_config(r#"{"puerto": 8080}"#)?;
    assert_eq!(config.puerto, 8080);
    Ok(()) // La prueba falla si cualquier ? retorna Err
}

Probando Pánicos

#[test]
#[should_panic]
fn panico_en_entrada_vacia() {
    process(&[]);
}

#[test]
#[should_panic(expected = "índice fuera de los límites")]
fn panico_con_mensaje_especifico() {
    let v: Vec<i32> = vec![];
    let _ = v[0];
}

Pruebas de Integración

Estructura de Archivos

my_crate/
├── src/
│   └── lib.rs
├── tests/              # Pruebas de integración
│   ├── api_test.rs     # Cada archivo es un binario de prueba separado
│   ├── db_test.rs
│   └── common/         # Utilidades de prueba compartidas
│       └── mod.rs

Escribiendo Pruebas de Integración

// tests/api_test.rs
use my_crate::{App, Config};

#[test]
fn ciclo_de_vida_completo_de_solicitud() {
    let config = Config::test_default();
    let app = App::new(config);

    let response = app.handle_request("/health");
    assert_eq!(response.status, 200);
    assert_eq!(response.body, "OK");
}

Pruebas Asíncronas

Con Tokio

#[tokio::test]
async fn obtiene_datos_exitosamente() {
    let client = TestClient::new().await;
    let result = client.get("/data").await;
    assert!(result.is_ok());
    assert_eq!(result.unwrap().items.len(), 3);
}

#[tokio::test]
async fn maneja_timeout() {
    use std::time::Duration;
    let result = tokio::time::timeout(
        Duration::from_millis(100),
        slow_operation(),
    ).await;

    assert!(result.is_err(), "debería haber excedido el tiempo");
}

Patrones de Organización de Pruebas

Pruebas Parametrizadas con rstest

use rstest::{rstest, fixture};

#[rstest]
#[case("hola", 4)]
#[case("", 0)]
#[case("rust", 4)]
fn test_longitud_cadena(#[case] input: &str, #[case] expected: usize) {
    assert_eq!(input.len(), expected);
}

// Fixtures
#[fixture]
fn test_db() -> TestDb {
    TestDb::new_in_memory()
}

#[rstest]
fn test_insertar(test_db: TestDb) {
    test_db.insert("clave", "valor");
    assert_eq!(test_db.get("clave"), Some("valor".into()));
}

Ayudantes de Prueba

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

    /// Crea un usuario de prueba con valores predeterminados sensatos.
    fn crear_usuario(nombre: &str) -> User {
        User::new(nombre, &format!("{nombre}@test.com")).unwrap()
    }

    #[test]
    fn visualizacion_usuario() {
        let user = crear_usuario("alice");
        assert_eq!(user.display_name(), "alice");
    }
}

Pruebas Basadas en Propiedades con proptest

Pruebas de Propiedades Básicas

use proptest::prelude::*;

proptest! {
    #[test]
    fn codificacion_decodificacion_roundtrip(input in ".*") {
        let encoded = encode(&input);
        let decoded = decode(&encoded).unwrap();
        assert_eq!(input, decoded);
    }

    #[test]
    fn ordenar_mantiene_longitud(mut vec in prop::collection::vec(any::<i32>(), 0..100)) {
        let original_len = vec.len();
        vec.sort();
        assert_eq!(vec.len(), original_len);
    }

    #[test]
    fn ordenar_produce_salida_ordenada(mut vec in prop::collection::vec(any::<i32>(), 0..100)) {
        vec.sort();
        for window in vec.windows(2) {
            assert!(window[0] <= window[1]);
        }
    }
}

Estrategias Personalizadas

use proptest::prelude::*;

fn correo_valido() -> impl Strategy<Value = String> {
    ("[a-z]{1,10}", "[a-z]{1,5}")
        .prop_map(|(usuario, dominio)| format!("{usuario}@{dominio}.com"))
}

proptest! {
    #[test]
    fn acepta_correos_validos(email in correo_valido()) {
        assert!(User::new("Test", &email).is_ok());
    }
}

Mocking con mockall

Mocking Basado en Traits

use mockall::{automock, predicate::eq};

#[automock]
trait UserRepository {
    fn find_by_id(&self, id: u64) -> Option<User>;
    fn save(&self, user: &User) -> Result<(), StorageError>;
}

#[test]
fn servicio_retorna_usuario_cuando_se_encuentra() {
    let mut mock = MockUserRepository::new();
    mock.expect_find_by_id()
        .with(eq(42))
        .times(1)
        .returning(|_| Some(User { id: 42, name: "Alice".into() }));

    let service = UserService::new(Box::new(mock));
    let user = service.get_user(42).unwrap();
    assert_eq!(user.name, "Alice");
}

#[test]
fn servicio_retorna_none_cuando_no_se_encuentra() {
    let mut mock = MockUserRepository::new();
    mock.expect_find_by_id()
        .returning(|_| None);

    let service = UserService::new(Box::new(mock));
    assert!(service.get_user(99).is_none());
}

Pruebas de Documentación

Documentación Ejecutable

/// Suma dos números.
///
/// # Ejemplos
///
/// ```
/// use my_crate::add;
///
/// assert_eq!(add(2, 3), 5);
/// assert_eq!(add(-1, 1), 0);
/// ```
pub fn add(a: i32, b: i32) -> i32 {
    a + b
}

/// Analiza una cadena de configuración.
///
/// # Errores
///
/// Retorna `Err` si la entrada no es TOML válido.
///
/// ```no_run
/// use my_crate::parse_config;
///
/// let config = parse_config(r#"puerto = 8080"#).unwrap();
/// assert_eq!(config.puerto, 8080);
/// ```
///
/// ```no_run
/// use my_crate::parse_config;
///
/// assert!(parse_config("}{invalid").is_err());
/// ```
pub fn parse_config(input: &str) -> Result<Config, ParseError> {
    todo!()
}

Benchmarks con Criterion

# Cargo.toml
[dev-dependencies]
criterion = { version = "0.5", features = ["html_reports"] }

[[bench]]
name = "benchmark"
harness = false
// benches/benchmark.rs
use criterion::{black_box, criterion_group, criterion_main, Criterion};

fn fibonacci(n: u64) -> u64 {
    match n {
        0 | 1 => n,
        _ => fibonacci(n - 1) + fibonacci(n - 2),
    }
}

fn bench_fibonacci(c: &mut Criterion) {
    c.bench_function("fib 20", |b| b.iter(|| fibonacci(black_box(20))));
}

criterion_group!(benches, bench_fibonacci);
criterion_main!(benches);

Cobertura de Pruebas

Ejecutando Cobertura

# Instalar: cargo install cargo-llvm-cov (o usar taiki-e/install-action en CI)
cargo llvm-cov                    # Resumen
cargo llvm-cov --html             # Reporte HTML
cargo llvm-cov --lcov > lcov.info # Formato LCOV para CI
cargo llvm-cov --fail-under-lines 80  # Fallar si está por debajo del umbral

Objetivos de Cobertura

Tipo de CódigoObjetivo
Lógica de negocio crítica100%
API pública90%+
Código general80%+
Enlaces generados / FFIExcluir

Comandos de Prueba

cargo test                        # Ejecutar todas las pruebas
cargo test -- --nocapture         # Mostrar salida de println
cargo test nombre_prueba          # Ejecutar pruebas que coincidan con el patrón
cargo test --lib                  # Solo pruebas unitarias
cargo test --test api_test        # Solo pruebas de integración
cargo test --doc                  # Solo pruebas de documentación
cargo test --no-fail-fast         # No detenerse en el primer fallo
cargo test -- --ignored           # Ejecutar pruebas ignoradas

Mejores Prácticas

HACER:

  • Escribir las pruebas PRIMERO (TDD)
  • Usar módulos #[cfg(test)] para pruebas unitarias
  • Probar el comportamiento, no la implementación
  • Usar nombres de prueba descriptivos que expliquen el escenario
  • Preferir assert_eq! sobre assert! para mejores mensajes de error
  • Usar ? en pruebas que retornan Result para una salida de error más limpia
  • Mantener las pruebas independientes — sin estado mutable compartido

NO HACER:

  • Usar #[should_panic] cuando se pueda probar Result::is_err() en su lugar
  • Mockear todo — preferir pruebas de integración cuando sea factible
  • Ignorar pruebas inestables — repararlas o ponerlas en cuarentena
  • Usar sleep() en pruebas — usar canales, barreras o tokio::time::pause()
  • Omitir pruebas de rutas de error

Integración CI

# GitHub Actions
test:
  runs-on: ubuntu-latest
  steps:
    - uses: actions/checkout@v4
    - uses: dtolnay/rust-toolchain@stable
      with:
        components: clippy, rustfmt

    - name: Verificar formato
      run: cargo fmt --check

    - name: Clippy
      run: cargo clippy -- -D warnings

    - name: Ejecutar pruebas
      run: cargo test

    - uses: taiki-e/install-action@cargo-llvm-cov

    - name: Cobertura
      run: cargo llvm-cov --fail-under-lines 80

Recuerda: Las pruebas son documentación. Muestran cómo se espera que se use tu código. Escríbelas claramente y mantenlas actualizadas.

Individual skills in this repo

This repo contains 20 individual skills — each has its own dedicated page.

accessibility

Design, implement, and audit inclusive digital products using WCAG 2.2 Level AA. Use when building or auditing UI that must meet WCAG 2.2 Level AA, or when reviewing a change for keyboard, contrast, or screen-reader support.

affaan-m/claude-api

Anthropic Claude API patterns for Python and TypeScript. Covers Messages API, streaming, tool use, vision, extended thinking, batches, prompt caching, and Claude Agent SDK. Use when building applications with the Claude API or Anthropic SDKs.

affaan-m/everything-claude-code

End-to-end marketing campaign planning and execution. Covers audience research, positioning, campaign angle definition, landing page copy, email sequences, social posts, ad copy, short-form video scripts, and content calendars. Use as the orchestration layer for multi-channel product launches. Use when planning or executing a multi-channel product launch, or producing landing page, email, social, or ad copy.

affaan-m/everything-claude-code

Development conventions and patterns for everything-claude-code. JavaScript project with conventional commits.

affaan-m/everything-claude-code-conventions

Development conventions and patterns for everything-claude-code. JavaScript project with conventional commits.

affaan-m/frontend-design

Create distinctive, production-grade frontend interfaces with high design quality. Use when the user asks to build web components, pages, or applications and the visual direction matters as much as the code quality.

affaan-m/gget

gget CLI and Python workflow for quick genomic database queries, sequence lookup, BLAST-style searches, enrichment checks, and reproducible bioinformatics evidence logs.

affaan-m/literature-review

Systematic literature-review workflow for academic, biomedical, technical, and scientific topics, including search planning, source screening, synthesis, citation checks, and evidence logging.

affaan-m/motion-ui

Production-ready UI motion system for React/Next.js. Use when implementing animations, transitions, or motion patterns.

affaan-m/project-guidelines-example

Example project-specific skill template based on a real production application.

affaan-m/pubmed-database

Direct PubMed and NCBI E-utilities search workflows for biomedical literature, MeSH queries, PMID lookup, citation retrieval, and API-backed literature monitoring.

affaan-m/scholar-evaluation

Structured scholarly-work evaluation for papers, proposals, literature reviews, methods sections, evidence quality, citation support, and research-writing feedback.

affaan-m/uspto-database

USPTO patent and trademark data workflow for official record lookup, PatentSearch queries, TSDR checks, assignment data, and reproducible IP research logs.

agent-architecture-audit

Full-stack diagnostic for agent and LLM applications. Audits the 12-layer agent stack for wrapper regression, memory pollution, tool discipline failures, hidden repair loops, and rendering corruption. Produces severity-ranked findings with code-first fixes. Essential for developers building agent applications, autonomous loops, or any LLM-powered feature. Use when an agent or LLM feature misbehaves and the failing layer is unknown, or before shipping an agent stack.

agent-eval

Head-to-head comparison of coding agents (Claude Code, Aider, Codex, etc.) on custom tasks with pass rate, cost, time, and consistency metrics. Use when choosing between coding agents, or when a change to an agent setup needs measured pass rate, cost, and time rather than an impression.

agent-harness-construction

Design and optimize AI agent action spaces, tool definitions, and observation formatting for higher completion rates. Use when defining or revising an agent

agentic-engineering

Operate as an agentic engineer using eval-first execution, decomposition, and cost-aware model routing. Use when planning or executing engineering work that agents will carry out end to end.

agentic-os

Build persistent multi-agent operating systems on Claude Code. Covers kernel architecture, specialist agents, slash commands, file-based memory, scheduled automation, and state management without external databases. Use when building a persistent multi-agent system on Claude Code with its own memory, commands, and scheduling.

agent-introspection-debugging

Structured self-debugging workflow for AI agent failures using capture, diagnosis, contained recovery, and introspection reports. Use when an agent run fails and you need a reproducible diagnosis instead of a retry.

agent-payment-x402

Add x402 payment execution to AI agents with per-task budgets, spending controls, and non-custodial wallets. Supports Base through agentwallet-sdk and X Layer through OKX Payments / OKX Agent Payments Protocol. Use when an agent must pay for something itself and needs per-task budgets, spending controls, and a non-custodial wallet.

Skills relacionados