Diferencias entre pruebas unitarias, de integración y end-to-end

Una prueba unitaria es la que verifica el comportamiento de una pieza pequeña y aislada del código, típicamente una función, un método o una clase, comprobando que ante ciertas entradas produce las salidas esperadas. Su rasgo definitorio es el aislamiento: la unidad bajo prueba se examina sin sus dependencias reales, que se sustituyen por versiones controladas y simuladas cuando hace falta, de modo que la prueba se concentra exclusivamente en la lógica de esa pieza y no en la de sus colaboradores. Este aislamiento le da dos grandes virtudes. La primera es la velocidad: al no involucrar bases de datos, redes ni sistemas externos, una prueba unitaria se ejecuta en milisegundos, lo que permite tener miles de ellas y correrlas continuamente durante el desarrollo. La segunda es la precisión en el diagnóstico: cuando una prueba unitaria falla, señala con exactitud qué pieza y qué comportamiento se rompió, sin ambigüedad, porque solo esa pieza estaba en juego. Por estas razones, las pruebas unitarias forman la base de la pirámide de testing y son donde conviene concentrar el mayor número de pruebas, especialmente para verificar lógica pura como cálculos, validaciones y reglas de negocio. Su límite, que hay que tener presente, es que al probar cada pieza por separado no comprueban que esas piezas encajen correctamente entre sí cuando trabajan juntas, algo que queda en manos de las pruebas de integración y de nivel superior.

Una prueba de integración es la que verifica que varias piezas del sistema funcionan correctamente cuando trabajan juntas, en lugar de examinarlas por separado como hacen las pruebas unitarias. Su objetivo es precisamente comprobar las costuras, es decir, los puntos donde distintos componentes se conectan e intercambian información, que es donde suelen aparecer errores que ninguna prueba unitaria puede detectar, porque cada pieza individual puede funcionar perfectamente por sí sola y aun así no encajar bien con las demás. Ejemplos típicos de pruebas de integración son verificar que el código de la aplicación interactúa correctamente con la base de datos real, guardando y recuperando datos como se espera; que dos módulos internos se comunican con los formatos y las expectativas correctas; o que la aplicación se integra bien con un servicio o una interfaz externa. A diferencia de las unitarias, las pruebas de integración usan dependencias reales o muy próximas a las reales, lo que las hace más lentas y algo más complejas de preparar, pero también más realistas en cuanto a la detección de problemas de acoplamiento. Ocupan la franja intermedia de la pirámide de testing, en cantidad moderada: menos que las unitarias pero más que las end-to-end. Su valor es cubrir el hueco que dejan las unitarias, ya que un sistema puede tener todas sus piezas correctamente probadas de forma aislada y sin embargo fallar en producción porque esas piezas no colaboran como se suponía, y la prueba de integración es la que atrapa ese tipo de fallo antes de que llegue al usuario.

Una prueba end-to-end, abreviada como e2e, es la que verifica un flujo completo de la aplicación de principio a fin, atravesando todo el sistema tal como lo haría un usuario real. En lugar de examinar una pieza o la conexión entre unas pocas, una prueba end-to-end reproduce un recorrido completo a través de todas las capas del sistema, por ejemplo abrir la aplicación web en un navegador, registrarse, iniciar sesión, agregar un producto al carrito y completar una compra, comprobando que todo el conjunto se comporta correctamente de extremo a extremo. Su gran virtud es el realismo: es el tipo de prueba que más se acerca a la experiencia real del usuario y la que da más confianza de que un camino crítico funciona de verdad en su totalidad, integrando interfaz, lógica, base de datos y servicios. Sin embargo, este realismo tiene un costo elevado en tres frentes. Son lentas, porque ejecutan el sistema completo y a menudo a través de un navegador real, por lo que cada prueba tarda mucho más que una unitaria. Son frágiles, porque al depender de tantas partes pueden fallar por motivos ajenos al código que se pretende probar, como demoras de red, tiempos de espera, cambios menores en la interfaz o particularidades del entorno, lo que genera fallos intermitentes molestos. Y son difíciles de diagnosticar, porque cuando una prueba end-to-end falla, el problema puede estar en cualquier punto del largo camino que recorre. Por todo ello, las pruebas end-to-end ocupan la estrecha punta de la pirámide de testing: conviene tener pocas, estables y reservadas para verificar los caminos verdaderamente críticos del producto, en lugar de intentar cubrir con ellas toda la funcionalidad.

La pirámide de testing es una heurística visual, muy conocida y difundida, que representa la proporción recomendada de pruebas de cada nivel en una suite de pruebas sana, y que se ilustra como un triángulo dividido en tres franjas horizontales. En la base ancha del triángulo están las pruebas unitarias, indicando que debe haber muchas, porque son rápidas, baratas y precisas. En la franja intermedia están las pruebas de integración, en cantidad moderada. Y en la punta estrecha están las pruebas end-to-end, indicando que debe haber pocas, porque son lentas, caras y frágiles. La lógica de fondo de esta forma es esencialmente económica y de eficiencia: conviene tener abundancia de las pruebas que son rápidas y localizan bien los fallos, y reservar las pruebas costosas y lentas para unos pocos casos que verifiquen los caminos críticos completos del sistema. La regla práctica que se deriva de la pirámide es probar cada cosa en el nivel más bajo que pueda proporcionar la confianza necesaria, evitando usar pruebas de alto nivel para lo que se puede verificar con pruebas de bajo nivel. Respetar la pirámide produce suites de pruebas rápidas, estables y fáciles de mantener, que el equipo ejecuta con frecuencia y en las que confía. El antipatrón opuesto, conocido como cono de helado, consiste en invertir la proporción con muchas pruebas end-to-end y pocas unitarias, y produce suites lentas, inestables y difíciles de diagnosticar, por lo que se considera algo a evitar. Conviene entender la pirámide como una guía orientativa y no como una regla rígida, adaptándola al contexto de cada proyecto.

La regla más útil para decidir en qué nivel probar algo es hacerlo en el nivel más bajo que pueda darte la confianza que necesitás sobre ese comportamiento concreto, ya que los niveles más bajos son más rápidos, más baratos y más precisos al diagnosticar. Siguiendo esta regla, la lógica pura, como los cálculos, las validaciones de datos y las reglas de negocio, se prueba con pruebas unitarias, porque son autocontenidas y no dependen de nada externo, de modo que una unitaria las cubre de forma exhaustiva y rapidísima. La correcta comunicación entre piezas, como la interacción del código con la base de datos, con una interfaz de programación o entre dos módulos internos, se prueba con pruebas de integración, porque ahí es donde se verifican las costuras que las unitarias no pueden ver al examinar cada pieza por separado. Los flujos críticos completos del producto, como el proceso de registro o el de compra recorridos como lo haría un usuario, se prueban con unas pocas pruebas end-to-end, que confirman que todo el sistema funciona junto en esos caminos que no pueden fallar. Para los componentes de interfaz de usuario existe además un nivel intermedio, el testing de componentes, que permite probar un componente de forma aislada pero renderizado de verdad, situándose entre la unidad y el end-to-end. Dos principios complementan esta decisión: evitar duplicar la misma verificación en varios niveles, porque encarece la suite sin aportar cobertura nueva, y no usar pruebas caras y lentas para lo que se puede verificar con pruebas baratas y rápidas. Aplicar estos criterios de forma consistente conduce de manera natural a la proporción de la pirámide y a una suite de pruebas eficiente y confiable.

No todos los proyectos necesitan los tres niveles con la misma intensidad, y la combinación adecuada depende del tipo de aplicación, de su tamaño, de su criticidad y del contexto del equipo, por lo que la pirámide debe entenderse como una guía orientativa y no como una obligación rígida. Dicho esto, la mayoría de los proyectos de cierta entidad se benefician de tener al menos pruebas unitarias abundantes, porque son la forma más económica y eficaz de proteger la lógica y de permitir cambios con confianza, y en casi cualquier proyecto vale la pena invertir en ellas. Las pruebas de integración cobran importancia en cuanto el sistema tiene piezas que colaboran, como una base de datos, servicios externos o varios módulos, que es el caso de la práctica totalidad de las aplicaciones reales, por lo que también suelen ser recomendables. Las pruebas end-to-end aportan más valor cuanto más crítico sea que ciertos flujos completos funcionen sin fallos, como en un comercio electrónico donde el proceso de compra no puede romperse, y en esos casos conviene tener unas pocas sobre los caminos esenciales; en proyectos muy pequeños o internos quizá baste con muy pocas o ninguna. También influye la naturaleza del proyecto: una biblioteca de cálculo puede vivir casi enteramente de pruebas unitarias, mientras que una aplicación web con mucha interacción de usuario necesitará más presencia de niveles superiores. Lo esencial es no caer en los extremos, ni descuidar por completo las pruebas ni invertir la pirámide llenando el proyecto de pruebas lentas y frágiles, sino razonar en cada caso qué mezcla de niveles ofrece la mejor relación entre confianza, velocidad y costo de mantenimiento para ese producto concreto.