La Pirámide de Tests Explicada para Ingenieros QA

Una funcionalidad de checkout necesita tres tests E2E, no treinta: uno para el camino feliz, uno para el fallo de pago, uno para el artículo sin stock. Los demás casos extremos son más baratos y más estables como tests unitarios y de API. Este artículo explica las tres capas de la pirámide, qué pasa cuando los equipos la invierten en un cono de helado, y la variante moderna (el trofeo de testing) que se adapta a aplicaciones con mucho frontend.

El modelo original

Mike Cohn introdujo la pirámide de testing en 2009. La versión original tenía tres capas:

        /\
       /  \
      / E2E \       ← pocos, lentos, costosos
     /--------\
    / Integración\  ← algunos
   /--------------\
  / Tests Unitarios \ ← muchos, rápidos, baratos
 /--------------------\

Tests unitarios (abajo)

Prueban funciones o clases individuales en aislamiento. Milisegundos de ejecución. Cientos o miles. Retroalimentación inmediata.

Tests de integración (medio)

Prueban cómo trabajan juntos los componentes: una capa de servicio llamando a una base de datos, un endpoint de API con middleware real. Segundos de ejecución. Decenas a cientos.

Tests E2E (arriba)

Prueban el sistema completo a través de un navegador o cliente de API. Minutos para ejecutar una suite completa. Decenas a pocos cientos.

La forma importa: muchos abajo, pocos arriba. La pirámide.

Por qué importa la forma

Si inviertes la pirámide, con muchos tests E2E y pocos tests unitarios, obtienes:

Una suite lenta (los tests E2E tardan entre 10 y 60 veces más que los tests unitarios)
Tests flaky (más piezas móviles = más modos de fallo)
Información de depuración deficiente (un fallo E2E te dice que algo está mal; un fallo unitario te dice exactamente qué)
Mantenimiento costoso (los cambios de UI rompen tests E2E; las APIs cambian con menos frecuencia)

El anti-patrón clásico es el cono de helado: una capa mínima de tests unitarios, sin capa de integración, y una suite E2E masiva que tarda 45 minutos en ejecutarse y falla aleatoriamente.

La interpretación moderna

La pirámide original es anterior a los microservicios, el serverless y frameworks como Playwright que hacen los tests E2E significativamente más confiables. La versión moderna lo reconoce:

        /\
       /  \
      / E2E \         ← smoke tests, caminos críticos
     /--------\
    /  API/Svc \      ← integración, tests de contrato
   /--------------\
  / Component/Unit \ ← lógica de negocio, utilidades
 /--------------------\

Las proporciones específicas varían según el equipo y el tipo de producto. Una API CRUD puede tener muy pocos tests E2E y cobertura pesada de API. Un dashboard React con UI compleja puede tener más tests de componente y menos tests unitarios.

El principio se mantiene: apóyate en los tests más baratos, rápidos y estables. Reserva E2E para los escenarios que solo pueden verificarse a través del stack completo.

Aplicar la pirámide a un proyecto Playwright

Qué pertenece a los tests E2E

Flujos críticos de usuario (login → checkout → confirmación)
Integración entre servicios (frontend + backend + base de datos juntos)
Comportamiento específico del navegador (carga de archivos, múltiples pestañas, redirección OAuth)
Smoke tests para deploys a producción

Qué no pertenece a los tests E2E

Mensajes de error de validación (prueba en tests unitarios de la lógica de validación)
Cada caso extremo de un algoritmo complejo (test unitario)
Respuestas de API en aislamiento (test de API)
Las 15 permutaciones de un formulario (particiona por equivalencia, elige 3-4 casos representativos para E2E)

Un ejemplo concreto

Estás probando una funcionalidad de colocación de pedidos. Los requisitos:

1. El usuario agrega un artículo al carrito

2. El usuario va al checkout

3. El usuario completa la información de envío

4. El usuario paga

5. Se muestra la confirmación del pedido

6. Se envía un email al usuario

Los tests unitarios cubren

Lógica de cálculo de precios (descuentos, impuestos, costos de envío)
Renderizado de la plantilla de email
Función de validación de dirección
Redondeo del monto de pago

Los tests de API/integración cubren

POST /orders crea un registro en la base de datos
POST /orders con pago inválido devuelve 422
Transiciones de estado del pedido (pendiente → confirmado → enviado)
El servicio de email se llama con los parámetros correctos

Los tests E2E cubren

El camino feliz (pedido completo desde el carrito hasta la confirmación, un test), el fallo de pago (tarjeta rechazada, error mostrado, pedido no creado, un test), y el caso sin stock (artículo no disponible, usuario redirigido con mensaje, un test).

Eso es todo. Tres tests E2E para una funcionalidad de checkout completa. Los tests unitarios y de API cubren los casos extremos: E2E cubre los flujos que más importan a los usuarios.

El trofeo de testing (modelo alternativo)

Kent C. Dodds propuso el trofeo de testing en 2018, que ajusta la pirámide para frontends JavaScript:

          /\
         /  \          ← E2E (pocos)
        /----\
       / Integr \      ← integración (la mayoría)
      /----------\
     /  Unitarios \    ← unitarios (algunos)
    /--------------\
   /    Estáticos   \  ← tipos, linting (siempre)
  /------------------\

La diferencia clave: los tests de integración en la parte superior del medio. Para apps React/Vue/Next.js, "tests de integración" significa renderizar componentes con sus dependencias reales (llamadas de API reales a un servidor de prueba, o una versión con mock a nivel de red). Esta es la filosofía de React Testing Library: probar cómo los usuarios interactúan con el componente, no los detalles de implementación.

Ambos modelos son válidos. La pirámide aplica bien a sistemas backend. El trofeo se adapta a aplicaciones con mucho frontend. Cualquiera de los dos le gana al cono de helado.

La regla práctica

Antes de escribir un test E2E, pregúntate: ¿qué está verificando este test que no podría verificarse en un nivel inferior?

Si la respuesta es "que el frontend y el backend están conectados y los datos fluyen correctamente a través de todo el stack", escribe el test E2E.

Si la respuesta es "que la validación del formulario muestra un error para un campo de email vacío", eso es un test unitario para la función de validación y un test de componente para el formulario. El test E2E solo sería ruido.