← dev-notes
TESTING · PARTE 1 DE 2

Testing
Fundamentos

Qué probar, con qué nivel de profundidad y cómo obtener feedback rápido

00Marco de calidad
Objetivo real del testing
  • Detectar riesgos temprano, no “subir porcentaje”.
  • Habilitar cambios seguros y frecuentes.
  • Documentar comportamiento esperado del sistema.
Errores de enfoque comunes
  • Medir éxito solo por cobertura de líneas.
  • Depender de e2e para validar lógica de negocio.
  • No tratar tests flaky como incidentes de calidad.
Regla práctica: cada bug en producción debería terminar en al menos una prueba nueva que impida su reaparición.
01Pirámide y tipos de prueba
🔺
01
Pirámide de testing
Más pruebas unitarias, menos e2e. Optimiza costo, velocidad y estabilidad del pipeline.
🧪
02
Unit tests
Validan reglas de negocio en aislamiento. Son la red más rápida para detectar regresiones.
🧩
03
Integration tests
Validan contratos entre módulos y adaptadores (BD, colas, HTTP), donde fallan muchas suposiciones.
EJEMPLO — TEST DE INTEGRACIÓN QUE SÍ APORTA (JAVA)
@Test
void shouldPersistOrderAndRecoverIt() {
    OrderRepository repository = new JpaOrderRepository(entityManager);
    Order order = Order.create(customerId, List.of(item("SKU-1", 2)));

    repository.save(order);
    Optional<Order> loaded = repository.findById(order.id());

    assertTrue(loaded.isPresent());
    assertEquals(order.total(), loaded.get().total());
}
02Diseño de pruebas efectivas
🎯
04
Una intención por test
Cada prueba debe fallar por una sola razón. Nombres explícitos ayudan a diagnosticar rápido.
📐
05
Arrange-Act-Assert
Estructura predecible: prepara, ejecuta y verifica. Mejora legibilidad y mantenimiento del suite.
MAL
Test largo con múltiples asserts sobre cosas no relacionadas; cuando falla, no sabes qué rompió.
BIEN
Un comportamiento por test, nombre expresivo y datos mínimos para explicar el caso.
03Métricas y cobertura
📊
06
Cobertura no es calidad
100% de líneas puede ocultar casos críticos no verificados. Mide riesgo cubierto, no solo porcentaje.
07
Feedback rápido
Prioriza tests que corren en segundos para mantener ritmo de desarrollo y evitar bypass de CI.
🧨
08
Flaky tests
Un test inestable cuesta confianza. Aísla dependencias de tiempo, red y orden de ejecución.
04Checklist de suite sana
PIPELINE
Feedback en minutos
La suite principal debe correr rápido para no desincentivar commits pequeños.
CONFIANZA
Cero flaky sin tratar
Un test inestable es deuda de calidad; se corrige o se desactiva temporalmente con ticket.
RELEVANCIA
Casos de riesgo cubiertos
Prioriza reglas críticas de negocio, límites y contratos con sistemas externos.
MANTENIBILIDAD
Tests legibles
Si cuesta entender una prueba, también costará mantenerla cuando cambie el sistema.