La pirámide de pruebas: cómo repartir tu automatización sin acabar con una suite inservible
Por qué las suites de extremo a extremo se vuelven lentas y frágiles, qué comprobación pertenece a cada nivel y cómo bajar de nivel las pruebas que están en el sitio equivocado.
El problema que resuelve la pirámide
Casi todas las suites de automatización que envejecen mal comparten la misma forma: cientos de pruebas de interfaz de usuario, unas pocas de servicio y casi ninguna unitaria. Es el antipatrón que se conoce como cono de helado, y produce un resultado predecible: la suite tarda horas, falla por motivos que no tienen que ver con el producto y acaba desconectada de la pipeline "hasta que la arreglemos".
La pirámide de pruebas no es una regla estética: es una consecuencia del coste. Cada nivel tiene un precio distinto por prueba, y no solo al escribirla, sino al ejecutarla y sobre todo al mantenerla.
| Nivel | Qué comprueba | Velocidad | Coste de mantenimiento |
|---|---|---|---|
| Unitario | Lógica de una función o clase aislada | Milisegundos | Bajo: cambia con el código que prueba |
| Integración / API | Contrato y comportamiento entre componentes | Decenas de milisegundos a segundos | Medio: estable si el contrato es estable |
| Sistema / E2E | Un flujo completo por la interfaz real | Segundos a minutos | Alto: cualquier cambio visual puede romperla |
La pregunta correcta no es "qué nivel", es "qué riesgo"
La forma útil de decidir el nivel de una prueba es preguntarse qué se rompería si esa comprobación no existiera, y dónde vive ese riesgo. El cálculo de un recargo por descubierto es lógica: prueba unitaria. Que el servicio de pagos devuelva un error 409 cuando el pedido ya está pagado es un contrato: prueba de API. Que un cliente pueda completar la compra desde el catálogo hasta el correo de confirmación es un flujo de negocio: eso sí merece una prueba de extremo a extremo.
El error clásico consiste en comprobar reglas de negocio a través de la interfaz porque "así se prueba como el usuario". Se paga tres veces: la prueba tarda más, se rompe con cada rediseño y, cuando falla, no dice qué regla se ha incumplido.
Cómo bajar de nivel una suite ya escrita
- Mide primero: duración total, duración por prueba y número de fallos por causa durante un mes. Sin esos datos, cualquier reorganización es una opinión.
- Agrupa las pruebas de interfaz por la regla que verifican. Verás que muchas comprueban variaciones de la misma lógica con distintos datos.
- Quédate con un solo camino feliz por flujo en la interfaz y traslada las variaciones al nivel de API o unitario.
- Reescribe la preparación de datos: crear el estado por servicio en lugar de navegando por pantallas suele recortar más tiempo que cualquier optimización de infraestructura.
- Borra lo redundante. Una suite más pequeña y fiable vale más que una grande que nadie mira.
Este trabajo se justifica con números, no con principios: si el coste de adaptar la suite a cada cambio del producto crece mes a mes y el tiempo de análisis de fallos se come las mañanas, la reorganización se paga sola.
Matices que la pirámide no cubre
La pirámide es un heurístico, no una ley. Hay contextos donde la forma cambia con razón. En una arquitectura de microservicios con equipos independientes, la capa de contrato crece hasta ser la más importante. En una aplicación cuyo valor está casi todo en la interfaz —un editor visual, un juego— hay más pruebas de interfaz de las que la pirámide sugeriría, y está bien. En sistemas embebidos, gran parte del esfuerzo se va a pruebas de integración con hardware simulado.
Lo que no cambia es el principio de fondo: pon cada comprobación en el nivel más barato y más estable que pueda detectar el problema. Todo lo demás son detalles del contexto.
En el examen CTAL-TAE
Este tema aparece en el capítulo 5 del syllabus, y casi siempre como escenario: una suite de extremo a extremo enorme y lenta, y cuatro opciones de las que solo una ataca la estructura. Las tentadoras suelen ser "paralelizar más" o "ejecutarla solo por la noche": ambas alivian el síntoma y dejan el problema intacto.