Pruebas de extremo a extremo frente a pruebas de integración: dónde debería realizarse realmente cada prueba

Las pruebas de extremo a extremo verifican que un usuario real puede completar un flujo de trabajo real a través de la interfaz real, con servicios reales conectados. Las pruebas de integración verifican que dos o más componentes se comunican correctamente a través de sus interfaces. Ambas forman parte de una estrategia sana de pruebas funcionales, y cada una detecta una categoría de errores que la otra no puede.

El punto de dolor está en el espacio entre esas dos definiciones. Un caso de prueba aterriza en la pizarra, la CI ya tarda 40 minutos, y la mitad del equipo lo quiere en integración porque es barato, mientras que la otra mitad lo quiere en E2E porque «toca la interfaz». Cada artículo sobre pruebas de extremo a extremo vs. pruebas de integración termina con el mismo encogimiento de hombros: usa ambas, sigue la pirámide 70/20/10, buena suerte. Ese consejo no te dice nada sobre la prueba que tienes delante.

Este artículo sí. Cuatro preguntas, cinco segundos por caso de prueba, ejemplos reales de proceso de pago. La elección se plantea como una decisión sobre el coste de la retroalimentación, porque eso es lo que es en realidad.

Por qué la regla 70/20/10 te deja atascado

La pirámide es un objetivo de distribución. Dice aproximadamente un 70 % unitarias, un 20 % de integración, un 10 % E2E, y ahí se queda. La distribución es el resultado de buenas decisiones de ubicación prueba a prueba, no algo que se consigue barajando pruebas entre capas hasta que la proporción parece correcta. Por eso el debate de pruebas E2E vs. de integración nunca se resuelve en la mayoría de los equipos: todos discuten sobre la proporción y nadie se pone de acuerdo sobre la regla.

Aparecen dos modos de fallo cuando los equipos tratan la pirámide como un consejo. El primero es el exceso de E2E. Todo lo que toca la interfaz se empuja hacia arriba; la suite se hincha hasta los 45 minutos; los desarrolladores dejan de ejecutarla en local; y la CI se convierte en un mero trámite. El segundo es el exceso de simulaciones en integración. Todo lo que está por debajo del navegador se sustituye por simulaciones para que las pruebas sean rápidas, la suite se mantiene en verde y producción se rompe ante un cambio en la forma de un webhook de Stripe que ninguna prueba ejercitó nunca contra la carga útil real.

Ambos fallos provienen de la misma causa raíz: nadie tenía una regla para decidir dónde encaja una prueba concreta. Esa es la brecha que estamos cerrando.

El filtro de ubicación de cuatro preguntas

Pasa cada nuevo caso de prueba por estas cuatro preguntas en orden. Cada una aísla una única decisión. Si las respuestas apuntan a un navegador real, servicios reales y una ruta de ingresos, la prueba se gana un puesto E2E. Si no, pertenece a la capa de integración, y tu presupuesto de CI te lo agradece.

Pregunta 1: ¿en qué capa está la aserción?

La aserción te dice dónde encaja la prueba. Toma una prueba de cupón: «aplicar un código de 15 % de descuento reduce el total del carrito».

Si la aserción es expect(response.discount).toBe(15), esto es una prueba de integración. Estás comprobando que el servicio de precios devolvió el número correcto. El navegador es irrelevante. Esta es la capa donde se sitúa nuestro trabajo de pruebas de API, y es donde debería vivir la mayor parte de la verificación de la lógica de negocio.

Si la aserción es expect(page.getByTestId(‘cart-total’)).toHaveText(‘$85.00’), esto es una prueba E2E. Estás comprobando que el número llegó al DOM, se renderizó en el elemento correcto y coincidió con lo que vería un usuario.

La misma lógica de negocio. Dos pruebas distintas. Dos hogares distintos. La regla: la capa de la aserción decide la capa de la prueba. Las pruebas de integración que hacen aserciones sobre texto renderizado son pruebas de integración mentirosas. O bien necesitan un navegador real (en cuyo caso son E2E) o una aserción distinta (en cuyo caso son integración bien hecha).

Pregunta 2: ¿el tercero es el sujeto o la fontanería?

Todo flujo de pago depende de servicios externos. Stripe, Twilio, Auth0, SendGrid. La pregunta es si el tercero es lo que estás probando o simplemente algo que la prueba toca de pasada.

Toma una prueba de tarjeta rechazada: «una tarjeta de Stripe rechazada muestra la pantalla de reintento».

Si estás verificando que los códigos de rechazo de Stripe se corresponden correctamente con tu taxonomía interna de errores, Stripe es el sujeto. Esto es una prueba de integración contra el modo de prueba de Stripe o un fixture grabado. Lo que te importa es si card_declined se convierte en PaymentFailedError.RetryableDecline en tu lado.

Si estás verificando que el usuario ve un botón de reintento, puede volver a introducir los datos de la tarjeta y obtiene un intento nuevo, Stripe es fontanería. La interfaz de reintento es el sujeto. Esto es una prueba E2E.

El error que cometen los equipos es empujar cualquier cosa que toque a un tercero hasta E2E porque «necesita el servicio real». No lo necesita. Necesita el servicio real solo cuando el servicio es aquello sobre lo que haces la aserción. Todo lo demás puede simular la fontanería y probar el sujeto real en el nivel más barato.

Pregunta 3: ¿un cambio de contrato rompería esta prueba aunque el comportamiento no cambie?

Toma una prueba de correo electrónico: «el correo de confirmación del pedido contiene el ID del pedido».

Si un servicio posterior cambia el nombre de orderId a order_id y esta prueba se rompe aunque el usuario siga recibiendo el correo correcto con el ID correcto, tienes una prueba de contrato disfrazada de prueba E2E. El registro de fallos dirá «se esperaba el campo orderId, se obtuvo order_id». Eso es un fallo de integración, y la integración es donde debería aflorar: rápido, barato y apuntando directamente al contrato roto.

Las pruebas E2E deberían fallar por el comportamiento, es decir, que el usuario obtuvo el resultado equivocado. Cuando fallan por la forma, es decir, que se cambia el nombre de un campo de la carga útil pero la experiencia del usuario es idéntica, el coste de depuración se multiplica aproximadamente por 10, porque estás persiguiendo una diferencia de JSON a través de un rastreo del navegador, capturas de pantalla y registros de red. Los fallos de contrato pertenecen a la capa de integración y se verifican mediante aserciones de esquema o una herramienta de pruebas de contrato.

Pregunta 4: ¿flujo crítico para los ingresos o rama secundaria?

No todo recorrido real del usuario se gana una prueba E2E. Toma una prueba de ajustes: «el usuario cambia las preferencias de notificación de un resumen semanal a uno diario».

Flujo de trabajo real. Escritura real en la base de datos. Impacto real en el usuario. Aun así, pertenece a la capa de integración. Cada prueba E2E que añades grava cada futura solicitud de incorporación de cambios (pull request), y ese impuesto se acumula. Reserva los puestos E2E para los flujos en los que un fallo es un acontecimiento que afecta a los ingresos: registro, inicio de sesión, proceso de pago, pago, mejora de la suscripción, recuperación de la cuenta. Todo lo demás se gana cobertura de integración a menos que haya un riesgo concreto de renderizado de la interfaz que solo un navegador pueda detectar.

Este es el enfoque que todo el SERP pasa por alto. Las pruebas de integración vs. las pruebas de extremo a extremo son una decisión sobre el coste de la retroalimentación. La economía lo refuerza: el informe de IBM sitúa el coste medio de una filtración en EE. UU. en un récord de 10,22 millones de dólares y, aunque no todo incidente de producción es una filtración, la misma asimetría se aplica a cualquier fallo en la ruta de ingresos. Gasta tu presupuesto de E2E allí donde un fallo te costaría un cliente.

Pruebas que ascendieron a E2E y no deberían haberlo hecho

Esta es la categoría de desperdicio más común en una suite E2E hinchada. Cada una de estas tiene una firma de fallo específica: la prueba falla, y la corrección es un cambio de una sola línea en un código que nunca necesitó un navegador para verificarse.

• Pruebas de validación de formularios. «El campo de correo electrónico rechaza las cadenas sin @». Esto pertenece a la capa de integración y debería probarse contra el validador. Si vive en E2E, estás pagando el coste de arrancar el navegador para probar una expresión regular.
• Pruebas de mapeo de errores de API. «Un error 500 del servicio de pago muestra “inténtalo de nuevo más tarde”». Prueba de integración en el gestor de errores. El navegador no es lo que mapea el error.
• Pruebas de persistencia en la base de datos. «Un formulario de contacto enviado aparece en el panel de administración». Dos pruebas de integración, una para la escritura y otra para la lectura, superan a una única prueba E2E inestable que abarca ambas y tarda 30 segundos por ejecución.
• Pruebas de indicadores de funcionalidad. «Los usuarios con el indicador X ven la variante B». Prueba de integración en la capa de resolución de indicadores. E2E solo si la propia variante visual conlleva un riesgo.
• Pruebas de permisos. «Un usuario que no es administrador no puede acceder a /admin». Prueba de integración en el middleware de autenticación. Cada ruta restringida envuelta en una prueba E2E es una suite que estarás podando dentro de seis meses.

Diagnóstico que puedes hacer en tu propio equipo esta semana: saca los últimos cinco fallos E2E. Si cada uno se pudiera arreglar mirando una respuesta de red en lugar de una captura de pantalla, tu suite se ha desplazado hacia abajo. La mitad pertenece a la capa de integración, y el reloj de la CI es el recibo.

Pruebas que descendieron a integración y rompieron producción

El error inverso es más raro, más caro y suele pasar desapercibido hasta que un cliente abre un ticket. Una prueba se baja a integración por velocidad; las simulaciones sustituyen a los servicios reales; todo se mantiene en verde; producción se rompe justo en aquello que las simulaciones ocultaban.

Los flujos de varios pasos con el estado retenido en el navegador son el caso clásico. La persistencia del carrito entre páginas, los asistentes de varios pasos, el proceso de pago basado en sesión. Cuando simulas la capa de sesión, también eliminas mediante simulación el error que se publica. Las redirecciones de terceros son otro caso. Las llamadas de retorno de OAuth, Stripe Checkout, el traspaso a PayPal. El viaje de ida y vuelta de la redirección es donde las cosas se rompen, y no existe en una prueba de integración. El comportamiento dependiente del CSS también pertenece a E2E: un botón de envío oculto detrás de una ventana modal porque un z-index cambió en la versión del martes no aflorará en ninguna capa por debajo de un navegador real. El comportamiento de las cookies entre orígenes, los cambios de SameSite y la autenticación en iframe caen todos en el mismo saco.

La regla: si el error solo aparecería en un navegador real comunicándose con servicios reales, la integración no puede hacerse cargo de él, por muy completas que sean las simulaciones. Los sistemas distribuidos intensifican este patrón, razón por la cual lo tratamos por separado en nuestro artículo sobre las pruebas de rendimiento de microservicios.

La división limpia

Dos declaraciones de responsabilidad resumen todo el artículo. La integración se hace cargo de:

• La comunicación entre servicios y la forma de lo que cruza el límite.
• Las comprobaciones de contrato: nombres de campos, tipos, códigos de error, esquemas de respuesta.
• La lógica de negocio por debajo del navegador: validación, mapeo de errores, permisos, resolución de indicadores de funcionalidad, lecturas y escrituras en la base de datos.
• Cualquier prueba en la que el tercero sea el sujeto de la aserción.
• Cualquier prueba en la que un fallo se manifieste como «respuesta incorrecta del servicio» en lugar de «cosa incorrecta en pantalla».

E2E se hace cargo de:

• La salida renderizada: la cosa correcta en la pantalla, en el lugar correcto, en el momento correcto.
• Los flujos de varios pasos con el estado transportado en el navegador.
• Las redirecciones y los viajes de ida y vuelta de terceros (llamadas de retorno de OAuth, Stripe Checkout, traspaso a PayPal).
• El comportamiento dependiente del CSS y del DOM (ventanas modales, z-index, botones ocultos, cookies entre orígenes).
• Los recorridos críticos para los ingresos en los que un fallo significa un cliente perdido.

Resumen en una línea: la integración demuestra que las piezas se comunican correctamente; E2E demuestra que el usuario llega hasta el final. Si una prueba intenta hacer ambas cosas, divídela en dos.

Ahora bien, la regla de ubicación es una herramienta de trabajo. Pasa cualquier prueba por las cuatro preguntas. Si la P1 responde «salida renderizada», la P2 responde «sujeto» y la P4 responde «crítico para los ingresos», la prueba se gana su puesto E2E. De lo contrario, por defecto va a integración. La elección del marco de trabajo viene en segundo lugar e importa menos de lo que la mayoría de los equipos creen. Tanto si tu equipo usa Cypress, Playwright o Selenium, la disciplina está en su sitio, y nuestra página sobre las pruebas automatizadas explica cómo lo llevamos a la práctica de extremo a extremo.

Dónde se gana su lugar cada prueba

La diferencia entre las pruebas de integración y las E2E no es una cuestión de taxonomía. Es una decisión prueba a prueba que da forma al reloj de tu CI, a tu tasa de incidentes en producción y a la confianza de tu equipo en la suite. Cuatro preguntas, aplicadas de forma coherente, sustituyen la discusión prueba por prueba por una regla que todo el equipo puede compartir.

Si tu suite se ha desviado, si la CI tarda 40 minutos cuando antes tardaba 8, o si producción se sigue rompiendo en cosas que tus pruebas de integración daban por buenas, contáctanos y auditaremos dónde viven realmente tus pruebas frente a dónde deberían.

Preguntas frecuentes

¿Cuál es la diferencia entre las pruebas de integración y las pruebas de extremo a extremo?

Las pruebas de integración verifican que dos o más componentes se comunican correctamente a través de sus interfaces. Las pruebas de extremo a extremo verifican que un usuario puede completar un flujo de trabajo a través de la interfaz real con servicios reales conectados. La diferencia práctica está en dónde se sitúa la aserción: en una respuesta del servicio o en lo que ve un usuario.

¿Cómo decido si un caso de prueba pertenece a integración o a E2E?

Pregúntate qué está comprobando la aserción. Si es una respuesta del servicio, un contrato o la forma de unos datos, pertenece a la capa de integración; si es un elemento renderizado o un flujo de usuario de varios pasos, pertenece a E2E. Cualquier prueba que seguiría aprobando con la interfaz rota no es una prueba E2E.

¿Cuándo bastan las pruebas de integración y cuándo se necesita E2E?

La integración basta cuando el tercero es el sujeto de la prueba, cuando un fallo se manifestaría como una respuesta incorrecta del servicio o cuando el flujo queda fuera de la ruta de ingresos. Necesitas E2E cuando el navegador transporta el estado a lo largo de los pasos, cuando intervienen redirecciones de terceros o cuando un fallo significa un cliente perdido en el registro, el proceso de pago o el pago.

¿Por qué mi suite de pruebas E2E es demasiado lenta?

Pruebas que pertenecen a la capa de integración se empujaron hacia arriba: la validación de formularios, el mapeo de errores, las comprobaciones de permisos y la resolución de indicadores de funcionalidad rara vez necesitan un navegador real. Audita los últimos cinco fallos E2E de tu proyecto y, si cada uno se pudiera arreglar con una respuesta de red en lugar de una captura de pantalla, la mayor parte de tu suite está en el lugar equivocado.