En testing existen distintos niveles de prueba. Cada nivel observa el software desde una distancia diferente y responde preguntas distintas. Comprender esas diferencias es importante para no esperar de una prueba algo que corresponde a otro nivel.
En este tema compararemos cuatro niveles muy habituales: pruebas unitarias, pruebas de integración, pruebas de sistema y pruebas end-to-end.
El foco principal de este curso son las pruebas de integración, pero para entenderlas bien necesitamos ubicarlas dentro del conjunto completo de pruebas.
Podemos imaginar los niveles de prueba como distintos grados de amplitud:
Una prueba unitaria verifica una unidad pequeña de código de forma aislada. Esa unidad puede ser una función, un método, una clase o un módulo simple. El objetivo es comprobar una lógica concreta sin depender de bases de datos, redes, archivos o servicios externos.
Por ejemplo, una prueba unitaria puede verificar que una función calcule correctamente el descuento de una compra o que una validación rechace un correo electrónico inválido.
Sus características principales son:
Una prueba de integración verifica que dos o más componentes colaboren correctamente. A diferencia de una prueba unitaria, aquí sí nos interesa que exista interacción entre partes del sistema.
Por ejemplo, una prueba de integración puede comprobar que un servicio reciba una solicitud, consulte una base de datos, aplique una regla de negocio y guarde el resultado esperado.
Sus características principales son:
Las pruebas de sistema evalúan el sistema completo como producto. El objetivo es verificar si cumple los requisitos definidos, tanto funcionales como no funcionales, en un ambiente representativo.
Por ejemplo, en un sistema de ventas, una prueba de sistema puede revisar que sea posible administrar productos, registrar clientes, generar pedidos, consultar reportes y aplicar reglas generales del negocio.
Sus características principales son:
Las pruebas end-to-end, también llamadas E2E, verifican un flujo completo de principio a fin. Observan el sistema desde la perspectiva de un usuario, un cliente externo o un proceso que atraviesa varias partes del producto.
Por ejemplo, una prueba end-to-end puede simular que un usuario inicia sesión, busca un producto, lo agrega al carrito, paga y recibe una confirmación.
Sus características principales son:
La siguiente tabla resume las diferencias principales:
| Nivel | Foco | Velocidad | Ejemplo |
|---|---|---|---|
| Unitaria | Una unidad aislada. | Muy alta. | Calcular el impuesto de una venta. |
| Integración | Colaboración entre componentes. | Media. | Guardar una venta y actualizar stock. |
| Sistema | Producto completo contra requisitos. | Media o baja. | Verificar el módulo completo de ventas. |
| End-to-end | Flujo completo desde el punto de vista del usuario. | Baja. | Comprar un producto desde la pantalla hasta la confirmación. |
Cada nivel tiene fortalezas distintas. No todos detectan los mismos problemas con la misma claridad.
| Tipo de error | Nivel donde suele detectarse mejor |
|---|---|
| Una fórmula matemática incorrecta. | Prueba unitaria. |
| Un servicio envía un campo con nombre incorrecto. | Prueba de integración. |
| Una funcionalidad completa no cumple un requisito. | Prueba de sistema. |
| El usuario no puede completar una compra desde la interfaz. | Prueba end-to-end. |
| Una variable de entorno apunta a una base de datos incorrecta. | Prueba de integración o de sistema. |
Supongamos una funcionalidad que permite crear una orden de compra. Podemos probarla en distintos niveles:
El mismo negocio se observa desde perspectivas diferentes. Ninguna de estas pruebas reemplaza completamente a las demás.
Como las pruebas end-to-end se parecen mucho al uso real, puede parecer tentador cubrir todo con ellas. Sin embargo, eso suele traer problemas.
Las pruebas end-to-end suelen ser más lentas, dependen de más partes y pueden fallar por causas muy distintas. Si una prueba completa falla, el problema puede estar en la interfaz, el backend, la base de datos, la red, un dato de prueba o un servicio externo.
Por eso es mejor combinar niveles. Las pruebas unitarias detectan errores pequeños con rapidez; las de integración validan colaboraciones; las de sistema revisan requisitos; y las end-to-end confirman flujos críticos completos.
También sería un error depender únicamente de pruebas unitarias. Aunque sean rápidas y valiosas, no verifican que el sistema conectado funcione correctamente.
Un proyecto puede tener muchas pruebas unitarias exitosas y aun así fallar porque:
Las pruebas de integración existen precisamente para cubrir ese espacio entre unidades aisladas y sistema completo.
Las pruebas de integración son el puente entre la lógica aislada y el comportamiento completo del sistema. Su lugar es especialmente importante cuando varias partes deben coordinarse para producir un resultado.
Son útiles para responder preguntas como:
La pirámide de pruebas es una idea usada para representar una estrategia equilibrada. En general, propone tener muchas pruebas unitarias, una cantidad intermedia de pruebas de integración y menos pruebas end-to-end.
No es una regla matemática, pero ayuda a pensar el balance. Si hay demasiadas pruebas amplias y pocas pruebas pequeñas, la suite puede volverse lenta e inestable. Si solo hay pruebas pequeñas, se pierde confianza sobre el sistema conectado.
Para decidir en qué nivel probar un caso, podemos hacernos estas preguntas:
Los niveles de prueba no compiten entre sí: se complementan. Una estrategia madura usa pruebas unitarias para validar lógica aislada, pruebas de integración para comprobar colaboraciones, pruebas de sistema para evaluar requisitos y pruebas end-to-end para confirmar recorridos críticos.
En este curso nos centraremos en el nivel de integración, porque allí aparecen muchos defectos importantes relacionados con contratos, datos, configuración, persistencia y dependencias.
En el próximo tema veremos con más detalle qué significa integrar componentes de software y cómo reconocer los límites entre las partes que deben colaborar.