Pregunta 191 / 200Básico Sin código

¿Qué es la pirámide de testing, y por qué muchos ingenieros senior dicen que la mayoría de los equipos invierte la proporción?

La pirámide de testing es una afirmación sobre costo y velocidad de feedback, no un reglamento, y la mayoría de los equipos con un CI lento e inestable la invirtieron sin darse cuenta.

APRENDE HACIENDOPon a prueba tu intuición3 pasos

Antes de leer la guía, escribe tu respuesta con un ejemplo concreto.

Usa los ejemplos y la explicación de la lección para comprobar tu idea.

Reflexión personal. No se envía a ningún servicio de IA.

#La Pirámide Es una Heurística Sobre Dónde Sale Más Barato Atrapar un Bug

La pirámide de testing es una afirmación simple sobre economía: cuanto más temprano y más acotado es un test, más barato resulta escribirlo, ejecutarlo y diagnosticar por qué falló, así que quieres muchos de esos, y progresivamente menos de los caros, amplios y de punta a punta. No es un mandato de escribir exactamente tres tipos de test, ni una afirmación sobre cuáles tests importan más. Es una afirmación sobre la proporción: en una suite saludable, los tests unitarios deberían superar ampliamente en número a los de integración, y estos a su vez deberían superar a los end-to-end completos.

#La Forma, Visualizada

Lee las flechas como "se apoya sobre, y cuesta más que". Un test unitario corre en milisegundos, sin red, sin base de datos y sin sistema de archivos: puedes correr diez mil de ellos en el tiempo que toma correr un solo test end-to-end manejado por navegador.

#Por Qué Importa la Forma: Velocidad, Costo y Confianza se Compensan Entre Sí

Capa	Proporción típica en una suite saludable	Tiempo de ejecución de la capa	Qué verifica realmente	Qué NO te dice
Unitarios	70-80%	Toda la capa en segundos, incluso con miles de tests	La lógica de una función o clase, sus ramas y casos límite, de forma aislada	Si las piezas están conectadas correctamente entre sí
Integración	15-20%	De segundos a pocos minutos	Que un componente se comunica correctamente con una dependencia real (o realista): una base de datos, una cola, un cliente HTTP contra un contrato	Si el flujo completo del usuario funciona de punta a punta
End-to-end	5-10%	Minutos, a veces decenas de minutos	Que un flujo real de usuario funciona contra el sistema desplegado, conectado de verdad	Por qué falló — un test E2E que falla te dice que algo se rompió, casi nunca dónde

Ninguna capa es "mejor" que otra: responden preguntas distintas. Lo que afirma la pirámide es solo sobre la proporción: como los tests unitarios son muchísimo más baratos de escribir y correr, y los E2E son muchísimo más caros de escribir, correr y depurar, la mayor parte de tu cobertura debería vivir en la base.

#La Pirámide Invertida (el "Cono de Helado")

#Por Qué los Equipos Terminan Así

Hay unas pocas causas raíz que se repiten en los códigos que terminan como cono de helado:

Arquitectura no testeable. Si la lógica de negocio está enredada con código de framework, una conexión a base de datos o un servidor web, no puedes testearla de forma unitaria sin mockear medio mundo, así que la gente deja de intentarlo y escribe un test E2E en su lugar, que al menos prueba algo real.
Desconfianza en los mocks. Los equipos que se quemaron con tests unitarios sobre-mockeados que pasaban mientras el sistema real estaba roto se van al extremo opuesto.
La cantidad de tests como proxy de cobertura. Los tests E2E se sienten más valiosos por test porque tocan más código, así que las métricas que premian el "número de tests" empujan a la gente a escribir menos tests, pero más pesados, en lugar de muchos pequeños.

#Cómo Suena una Respuesta Senior en una Entrevista

El entrevistador no está comprobando si sabés definir "test unitario". Está comprobando si notás cuando la forma de una suite está mal y si podés articular el arreglo en términos de costo y ciclo de feedback, no de dogma.

Tip

Una buena respuesta nombra el trade-off explícitamente: "Los tests unitarios son baratos y rápidos, así que deberían atrapar la mayoría de los bugs de lógica antes de que corra cualquier cosa más lenta. Los tests de integración existen para verificar las costuras: los lugares que la lógica pura no puede alcanzar, como una consulta SQL real o un esquema de mensaje real. Los tests end-to-end existen para verificar que esas costuras están conectadas correctamente para un puñado de flujos críticos de usuario, no para re-verificar lógica que ya está cubierta más abajo." Después, si te preguntan qué harías frente a una pirámide invertida, hablá de extraer la lógica de las capas no testeables para que se vuelva testeable a nivel unitario, en lugar de responder "escribir más tests unitarios" como si fuera un eslogan.

#Un Default Razonable, y Por Qué Es Solo un Default

Una proporción aproximada que suele citarse es 70% unitarios, 20% integración, 10% end-to-end, pero la proporción correcta depende del perfil de riesgo de tu sistema. Un servicio muy CRUD, con lógica de negocio delgada, puede apoyarse más en tests de integración, porque el riesgo real está en las queries a la base de datos y la serialización, no en ramas de lógica. Un servicio con un motor de reglas o lógica de pricing debería apoyarse más fuerte en tests unitarios, porque ahí es donde se esconden los bugs caros. Recitar una proporción fija sin poder justificarla para tu propio sistema es exactamente el tipo de respuesta que separa "memoricé el diagrama" de "entiendo por qué existe el diagrama".

🧠 Check your understanding
0/2 · 0/2 answered
1. La suite de CI de un equipo tiene 20 tests unitarios, 30 de integración y 150 tests end-to-end lentos manejados por navegador. ¿Qué describe esto?
2. ¿Por qué deberían los tests unitarios representar la mayor proporción de una suite saludable?

Diseña un pipeline de procesamiento de pedidos orientado a eventos, desde que se coloca el pedido hasta su cumplimiento ¿Qué es el testing de contratos entre servicios (por ejemplo, con Pact), y cómo evita la necesidad de un entorno de integración completo?